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INTRODUCTION 


The Transport Protocol Standard is one of a set of International 
Standards produced to facilitate the interconnection of computer 
systems. The set of standards covers the services and protocols 
required to achieve such interconnection. 


The Transport Protocol Standard is positioned with respect to 
other related standards by the layers defined in the Reference 
Model for Open Systems Interconnection (ISO 7498). It is most 
closely related to, and lies within the field of application of 
the Transport Service Standard (DP 8072). It also uses and makes 
reference to the Network Service Standard (DP 8348), whose 
provisions it assumes in order to accomplish the transport 
protocol’s aims. The interelationship of these standards is 
depicted in figure 1. 


Transport --- Reference to aims -------------- 
Protocol 
Specification | --- Reference to assumptions ------- 


Relationaship between Transport Protocol and adjacent services 
Figure 1 


The International Standard specifies a common encoding and a 
number of classes of transport protocol procedures to be used 
with different network qualities of service. 


It is intended that the Transport Protocol should be simple but 
general enough to cater for the total range of Network Service 
qualities possible, without restricting future extensions. 


The protocol is structured to give rise to classes of protocol 
which are designed to minimize possible incompatibilities and 
implementation costs. 


The classes are selectable with respect to the Transport and 
Network Services in providing the required quality of service for 
the interconnection of two session entities (note that each class 
provides a different set of functions for enhancement of service 
qualities). 


This protocol standard defines mechanisms that can be used to 
optimize network tariffs and enhance the following qualities of 
service: 


a) different throughput rates; 

b) different error rates; 

c) integrity of data requirements; 
d) reliability requirements. 


It does not require an implementation to use all of these 
mechanisms, nor does it define methods for measuring achieved 
quality of service or criteria for deciding when to release 
transport connections following quality of service degradation. 


The primary aim of this International Standard is to provide a 
set of rules for communication expressed in terms of the 
procedures to be carried out by peer entities at the time of 
communication. These rules for communication are intended to 
provide a sound basis for development in order to serve a variety 
of purposes: 


a) as a guide for implementors and designers; 
b) for use in the testing and procurement of equipment; 


c) as part of an agreement for the admittance of systems into 
the open systems environment; 


d) as a refinement of the understanding of OSI. 


It is expected that the initial users of the International 
Standard will be designers and implementors of equipment and the 
International Standard contains, in notes or in annexes, guidance 
on the implementation of the procedures defined in the standard. 


It should be noted that, as the number of valid protocol 
sequences is very large, it is not possible with current 
technology to verify that an implementation will operate the 
protocol defined in this International Standard correctly under 


all circumstances. It is possible by means of testing to 
establish confidence that an implementation correctly operates 
the protocol in a representative sample of circumstances. It is, 


however, intended that this International Standard can be used in 
circumstances where two implementations fail to communicate in 
order to determine whether one or both have failed to operate the 
protocol correctly. 


This International Standard contains a section on conformance of 


equipment claiming to implement the procedures in this 
International Standard. Attention is drawn to the fact that the 
standard does not contain any tests to demonstrate this 
conformance. 


The variations and options available within this International 
Standard are essential to enable a Transport Service to be 
provided for a wide variety of applications over a variety of 
network qualities. Thus, a minimally conforming implementation 
will not be suitable for use in all possible circumstances. It 
is important, therefore, to qualify all references to this 
International Standard with statements of the options provided or 
required or with statements of the intended purpose of provision 
or use. 


1 SCOPE AND FIELD OF APPLICATION 


1.1 This International Standard specifies: 


a) five classes of procedures: 
1) Class 0. Simple class; 
2) Class 1. Basic error recovery class; 
3) Class 2. Multiplexing class; 
4) Class 3. Error recovery and multiplexing class; 
5) Class 4. Error detection and recovery class, 


for the connection oriented transfer of data and control 
information from one transport entity to a peer transport 
entity; 


b) the means of negotiating the class of procedures to be 
used by the transport entities; 


c) the structure and encoding of the transport protocol data 
units used for the transfer of data and control 
information; 


1.2 The procedures are defined in terms of: 


a) the interactions between peer transport entities through 
the exchange of transport protocol data units; 


b) the interactions between a transport entity and the 
transport service user in the same system through the 
exchange of transport service primitives; 


c) the interactions between a transport entity and the 
network service provider through the exchange of network 
service primitives. 


These procedures are defined in the main text of the standard 
supplemented by state tables in annex A. 


1.3 


These procedures are applicable to instances of communication 
between systems which support the Transport Layer of the OSI 
Reference Model and which wish to interconnect in an open systems 
environment. 


This International Standard also specifies conformance 
requirements for systems implementing these procedures. It does 
not contain tests which can be used to demonstrate this 
conformance. 


2 REFERENCES 


ISO 7498 Information processing systems = Open systems 
interconnection - Basic Reference Model 


DP 8072 Information processing systems = Open systems 
interconnection - Transport service definition 

DP 8348 Information processing systems = Open systems 
interconnection - Connection-oriented network service 
definition. 


SECTION ONE. GENERAL 


3 DEFINITIONS 


NOTE - The definitions contained in this clause make use of 
abbreviations defined in clause 4. 


340 
This International Standard is based on the concepts developed in 
the Reference Model for Open Systems Interconnection (DIS 7498) 
and makes use of the following terms defined in that standard: 

a) concatenation and separation; 

b) segmenting and reassembling; 

c) multiplexing and demultiplexing; 


d) splitting and recombining; 


e) flow control. 


3.2 


For the purpose of this International Standard, the following 
definitions apply: 


3.2.1 equipment: 


Hardware or software or a combination of both; it need not be 
physically distinct within a computer system. 


3.2.2 transport service user: 


An abstract representation of the totality of those entities 
within a single system that make use of the transport service. 


3.2.3 network service provider: 


An abstract machine that models the totality of the entities 
providing the network service, as viewed by a transport entity. 


3.2.4 local matter: 
A decision made by a system concerning its behavior in the 


Transport Layer that is not subject to the requirements of this 
protocol. 


3.2.5 initiator: 


A transport entity that initiates a CR TPDU. 


3.2.6 responder: 


A transport entity with whom an initiator wishes to establish a 
transport connection. 


NOTE - Initiator and responder are defined with respect to a 


Single transport connection. A transport entity can be both an 
initiator and responder simultaneously. 


3.2.7 sending transport entity: 


A transport entity that sends a given TPDU. 


3.2.8 receiving transport entity: 


A transport entity that receives a given TPDU. 


3.2.9 preferred class: 


The protocol class that the initiator indicates in a CR TPDU as 
its first choice for use over the transport connection. 


3.2.10 alternative class: 


A protocol class that the initiator indicates in a CR TPDU as an 
alternative choice for use over the transport connection. 


3.2.11 proposed class: 


A preferred class or an alternative class. 


3.2.12 selected class: 


The protocol class that the responder indicates in a CC TPDU that 
it has chosen for use over the transport connection. 


3.2.13 proposed parameter: 


The value for a parameter that the initiator indicates in a CR 
TPDU that it wishes to use over the transport connection. 


3.2.14 selected parameter: 


The value for a parameter that the responder indicates in a CC 
TPDU that it has chosen for use over the transport connection. 


3.2.15 error indication: 


An N-RESET indication, or an N-DISCONNECT indication with a 
reason code indicating an error, that a transport entity receives 
from the NS-provider. 


3.2.16 invalid TPDU: 


A TPDU that does not comply with the requirements of this 
International Standard for structure and encoding. 


3.2.17 protocol error: 


A TPDU whose use does not comply with the procedures for the 
class. 


3.2.18 sequence number: 


a) The number in the TPDU-NR field of a DT TPDU that 
indicates the order in which the DT TPDU was transmitted 
by a transport entity. 


b) The number in the YR-TU-NR field of an AK or RJ TPDU that 
indicates the sequence number of the next DT TPDU expected 
to be received by a transport entity. 


3.2.19 transmit window: 


The set of consecutive sequence numbers which a transport entity 
has been authorized by its peer entity to send at a given time on 
a given transport connection. 
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3.2.20 lower window edge: 


The lowest sequence number in a transmit window. 


3.2.21 upper window edge: 


The sequence number which is one greater than the highest 
sequence number in the transmit window. 


3.2.22 upper window edge allocated to the peer entity: 


The value that a transport entity communicates to its peer entity 
to be interpreted as its new upper window edge. 


3.2.23 closed window: 


A transmit window that contains no sequence number. 


3.2.24 window information: 


Information contained in a TPDU relating to the upper and the 
lower window edges. 
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3.2.25 frozen reference: 


A reference that is not available for assignment to a connection 
because of the requirements of 6.18. 


3.2.26 unassigned reference: 


A reference that is neither currently in use for identifying a 
transport connection or which is in a frozen state. 


3.2.27 transparent (data): 
TS-user data that is transferred intact between transport 


entities and which is unavailable for use by the transport 
entities. 


3.2.28 owner (of a network connection): 


The transport entity that issued the N-CONNECT request leading to 
the creation of that network connection. 


3.2.29 retained TPDU: 
A TPDU that is subject to the retransmission procedure or 


retention until acknowledgement procedure and is available for 
possible retransmission. 
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4 SYMBOLS AND ABBREVIATIONS 


4.1 Data units 


TPDU Transport protocol data unit 
TSDU Transport service data unit 
NSDU Network service data unit 


4.2 Types of transport protocol data units 


CR TPDU Connection request TPDU 

CC TPDU Connection confirm TPDU 
DR TPDU Disconnect request TPDU 

DC TPDU Disconnect confirm TPDU 

DT TPDU Data TPDU 

ED TPDU Expedited data TPDU 

AK TPDU Data acknowledge TPDU 

EA TPDU Expedited acknowledge TPDU 
RJ TPDU Reject TPDU 

ER TPDU Error TPDU 


4.3 TPDU fields 


LI Length indicator (field) 

CDT Credit (field) 

TSAP-ID Transport service access point 
identifier (field) 

DST-REF Destination reference (field) 

SRC-REF Source reference (field) 

EOT End of TSDU mark 

TPDU-NR DT TPDU number (field) 

ED-TPDU-NR ED TPDU number (field) 

YR-TU-NR Sequence number response (field) 

YR-EDTU-NR ED TPDU number response (field) 
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.4 Times and associated variables 


.5 Miscellaneous 


TS-user 
TSAP 
NS-provider 
NSAP 

QOS 


Elapsed time between retransmissions 

The maximum number of transmissions 

Bound on reference 

Inactivity time 

Window time 

Time to try reassignment/resynchronization 

Time to wait for 
reassignment/resynchronization 

Supervisory timer 1 

Supervisory time 2 

NSDU lifetime local-to-remote 

NSDU lifetime remote-to-local 

Expected maximum transit delay 
local-to-remote 

Expected maximum transit delay 
remote-to-local 

Persistence time 

Local acknowledgement time 

Remote acknowledgement time 


Transport service user 
Transport service access point 
Network service provider 
Network service access point 
Quality of service 
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5 OVERVIEW OF THE TRANSPORT PROTOCOL 


NOTE - This overview is not exhaustive and has been provided for 
guidance to the reader of this International Standard. 


5.1 Service provided by the transport layer 


The protocol specified in this International Standard supports 
the transport service defined in DP 8072. 


Information is transferred to and from the TS-user in the 
transport service primitives listed in table 1. 
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| T-EXPEDITED DATA request 


| indication 
| T-DISCONNECT request TS User-Data 
| T-DISCONNECT indication Disconnect reason, 


TS User-Data. 


+  _  _ — —  _ _ _ _  _  _ _ _ _  _ _ _  _  _ __ _ _ eo ——————— —— 
| Primitive | Parameter 
A Sas ee E | ---------------------------- 
| T-CONNECT request | Called Address, 
| indication | Calling Address, 
| | Expedited Data option, 
Quality of Service, 
TS User-Data. 
| -------------------------------- | ---------------------------- 
| T-CONNECT response | Responding Address, 
| confirm | Quality of Service, 
| | Expedited Data option, 
| | TS User-Data. 
| T-DATA request | TS User-Data 
| indication | 
| 
| 
| 
| 
| 
| 


Table 1. Transport service primitives 


5.2 Service assumed from the network layer 


The protocol specified in this International Standard assumes 
use of the network service defined in DP 8348. 


Information is transferred to and from the NS-provider in 
network service primitives listed in table 2. 
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the 


the 


| N-CONNECT 


request 
indication 
response 
confirm 


request 
indication 


|N-DATA ACKNOWLEDGE 


request 
indication 


request 
indication 


request 
indication 
response 
confirm 


request 
indication 
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Called Address, 
Calling Address, 

NS User-Data, 

QOS parameter set, 
Responding address, 
Receipt confirmation 
selection. 


NS User-Data, 
Confirmation request 


Originator, 
Reason. 


NS User-Data. 
Originator, 
Reason. 


Network service primitives 


Table 2. 


Key: 


X - The Transport Protocol assumes that this facility is 
provided in all networks. 


Y - The Transport Protocol assumes that this facility is 
provided in some networks and a mechanism is provided to 
optionally use the facility. 


Z - The Transport Protocol does not use this parameter. 
NOTES: 
1 - The parameters listed in this table are those in the 


current network service (first DP 8348). 


2 - The way the parameters are exchanged between the transport 
entity and the NS-provider is a local matter. 


5.3 Functions of the Transport Layer 
5.3.1 Overview of functions 


The functions in the Transport Layer are those necessary to 
bridge the gap between the services available from the Network 
Layer and those to be offered to the TS-users. 


The functions in the Transport Layer are concerned with the 
enhancement of quality of service, including aspects of cost 
optimization. 


These functions are grouped below into those used at all times 
during a transport connection and those concerned with connection 
establishment, data transfer and release. 

NOTE - This International Standard does not include the following 
functions which are under consideration for inclusion in future 


editions of this standard: 


a) encryption; 
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b) accounting mechanisms; 

c) status exchanges and monitoring of QOS; 
d) blocking; 

e) temporary release of network connections; 


f) alternative checksum algorithm. 


5.3.1.1 Functions used at all times 


The following functions, depending upon the selected class and 
options, are used at all times during a transport connection: 


a) transmission of TPDUs (see 6.2 and 6.9); 


b) multiplexing and demultiplexing (see 6.15), a function 
used to share a single network connection between two or 
more transport connections; 


c) error detection (see 6.10, 6.13 and 6.17), a function used 
to detect the loss, corruption, duplication, misordering 
or misdelivery of TPDUs; 


d) error recovery (see 6.12, 6.14, 6.18, 6.19, 6.20, 6.21 and 
6.22), a function used to recover from detected and 
signalled errors. 


5.3.1.2 Connection Establishment 


The purpose of connection establishment is to establish a 
transport connection between two TS-users. The following 
functions of the transport layer during this phase must match the 
TS-users’ requested quality of service with the services offered 
by the network layer: 
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Dede ETE 


select network service which best matches the requirement 
of the TS-user taking into account charges for various 
services (see 6.5); 


decide whether to multiplex multiple transport connections 
onto a single network connection (see 6.5); 


establish the optimum TPDU size (see 6.5); 


select the functions that will be operational upon 
entering the data transfer phase (see 6.5); 


map transport addresses onto network addresses; 


provide a means to distinguish between two different 
transport connections (see 6.5); 


transport of TS-user data (see 6.5). 


Data Transfer 


The purpose of data transfer is to permit duplex transmission of 


TSDUs 
connect 


between the two TS-users connected by the transport 
ion. This purpose is achieved by means of two-way 


simultaneous communication and by the following functions, some 


of whic 
the sel 


a) 


h are used or not used in accordance with the result of 
ection performed in connection establishment: 


concatenation and separation (see 6.4), a function used to 
collect several TPDUs into a single NSDU at the sending 
transport entity and to separate the TPDUs at the 
receiving transport entity; 


segmenting and reassembling (see 6.3), a function used to 
segment a single data TSDU into multiple TPDUs at the 
sending transport entity and to reassemble them into their 
original format at the receiving transport entity; 
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c) splitting and recombining (see 6.23), a function allowing 
the simultaneous use of two or more network connections to 
support the same transport connection; 


d) flow control (see 6.16), a function used to regulate the 
flow of TPDUs between two transport entities on one 
transport connection; 

e) transport connection identification, a means to uniquely 
identify a transport connection between the pair of 
transport entities supporting the connection during the 
lifetime of the transport connection; 

f) expedited data (see 6.11), a function used to bypass the 
flow control of normal data TPDU. Expedited data TPDU 


flow is controlled by separate flow control; 


g) TSDU delimiting (see 6.3), a function used to determine 
the beginning and ending of a TSDU. 


5.3.1.4 Release 
The purpose of release (see 6.7 and 6.8) is to provide 


disconnection of the transport connection, regardless of the 
current activity. 


5.4 Classes and options 
5.4.1 General 


The functions of the Transport Layer have been organized into 
classes and options. 


A class defines a set of functions. Options define those 
functions within a class which may or may not be used. 


This International Standard defines five classes of protocol: 
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a) Class 0: Simple Class; 
b) Class 1: Basic Error recovery Class; 


c) Class 2: Multiplexing Class; 


d) Class 3: Error Recovery and Multiplexing Class; 
e) Class 4: Error Detection and Recovery Class. 
NOTE - Transport connections of classes 2, 3 and 4 may be 


multiplexed together onto the same network connection. 


5.4.2 Negotiation 


The use of classes and options is negotiated during connection 
establishment. The choice made by the transport entities will 
depend upon: 


a) the TS-users” requirements expressed via T-CONNECT service 
primitives; 


b) the quality of the available network services; 


c) the user required service versus cost ratio acceptable to 
the TS-user. 


5.4.3 Choice of network connection 


The following list classifies network services in terms of 
quality with respect to error behavior in relation to user 
requirements; its main purpose is to provide a basis for the 
decision regarding which class of transport protocol should be 
used in conjunction with given network connection: 
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a) Type A. Network connection with acceptable residual error 
rate (for example not signalled by disconnect or reset) 
and acceptable rate of signalled errors. 


b) Type B. Network connections with acceptable residual 
error rate (for example not signalled by disconnect or 


reset) but unacceptable rate of signalled errors. 


c) Type C. Network connections with unacceptable residual 
error rate. 


It is assumed that each transport entity is aware of the quality 
of service provided by particular network connections. 


5.4.4 Characteristics of Class 0 
Class 0 provides the simplest type of transport connection and is 
fully compatible with the CCITT recommendation S.70 for teletex 


terminals. 


Class 0 has been designed to be used with type A network 
connections. 


5.4.5 Characteristics of Class 1 


Class 1 provides a basic transport connection with minimal 
overheads. 


The main purpose of the class is to recover from network 
disconnect or reset. 


Selection of this class is usually based on reliability criteria. 


Class 1 has been designed to be used with type B network 
connections. 
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5.4.6 Characteristics of Class 2 
5.4.6.1 General 


Class 2 provides a way to multiplex several transport connections 
onto a single network connection. This class has been designed 
to be used with type A network connections. 


5.4.6.2 Use of explicit flow control 


The objective is to provide flow control to help avoid congestion 
at transport-connection-end-points and on the network connection. 
Typical use is when traffic is heavy and continuous, or when 
there is intensive multiplexing. Use of flow control can 
optimize response times and resource utilization. 


5.4.6.3 Non-use of explicit flow control 


The objective is to provide a basic transport connection with 
minimal overheads suitable when explicit disconnection of the 


transport connection is desirable. The option would typically be 
used for unsophisticated terminals, and when no multiplexing onto 
network connections is required. Expedited data is never 
available. 


5.4.7 Characteristics of Class 3 


Class 3 provides the characteristics of Class 2 plus the ability 
to recover from network disconnect or reset. Selection of this 
class is usually based upon reliability criteria. Class 3 has 
been designed to be used with type B network connections. 
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5.4.8 Characteristics of Class 4 


Class 4 provides the characteristics of Class 3, plus the 
capability to detect and recover from errors which occur as a 
result of the low grade of service available from the NS- 


provider. The kinds of errors to be detected include: TPDU 
loss, TPDU delivery out of sequence, TPDU duplication and  TPDU 
corruption. These errors may affect control TPDUs as well as 
data TPDUs. 


This class also provides for increased throughput capability and 
additional resilience against network failure. Class 4 has been 
designed to be used with type C network connections. 


5.5 Model of the transport layer 


A transport entity communicates with its TS-users through one or 
more TSAPs by means of the service primitives as defined by the 
transport service definition DP 8072. Service primitives will 
cause or be the result of transport protocol data unit exchanges 
between the peer transport entities supporting a transport 
connection. These protocol exchanges are effected using the 
services of the Network Layer as defined by the Network Service 
Definition DP 8348 through one or more NSAPs. 


Transport connection endpoints are identified in end systems by 
an internal, implementation dependent, mechanism so that the TS- 
user and the transport entity can refer to each transport 
connection. 
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Lo | TSAP |------------------------| TSAP |---------- 
4+------ + 4+------ + 
| | 
4+--------------- + 4+--------------- + 
| Transport | | Transport | 
| entity | | entity | 
4+--------------- + 4+--------------- + 
| | 
| | 
4+------ + 4+------ + 
Lo | NSAP |------------------------| NSAP |---------- 
4+------ + 4+------ + 
| | 
4------------------------------- + 


NOTE - For 
TSAP and 
instances, 
associated 


Figure 2 . Model of the transport layer 


purpose of illustration, this figure shows only one 
one NSAP for each transport entity. In certain 
more than one TSAP and/or more than one NSAP may be 
with a particular transport entity. 
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SECTION TWO. TRANSPORT PROTOCOL SPECIFICATION 


6 ELEMENTS OF PROCEDURE 


This clause contains elements of procedure which are used in the 
specification of protocol classes in clauses 7 to 12. These 
elements are not meaningful on their own. 


The procedures define the transfer of TPDUs whose structure and 
coding is specified in clause 13. Transport entities shall 
accept and respond to any TPDU received in a valid NSDU and may 
issue TPDUs initiating specific elements of procedure specified 
in this clause. 


NOTE - Where network service primitives and TPDUs and parameters 
used are not significant for a particular element of procedure, 
they have not been included in the specification. 


6.1 Assignment to network connection 
6.1.1 Purpose 


The procedure is used in all classes to assign transport 
connections to network connections. 


6.1.2 Network service primitives 


The procedure makes use of the following network service 
primitives: 


a) N-CONNECT; 


b) N-DISCONNECT. 
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6.1.3 Procedure 


Each transport connection shall be assigned to a network 
connection. The initiator may assign the transport connection to 
an existing network connection of which it is the owner or to a 
new network connection (see Note 1) which it creates for this 
purpose. 


The initiator shall not assign or reassign the transport 
connection to an existing network connection if the protocol 
class(es) proposed or the class in use for the transport 
connection are incompatible with the current usage of the network 
connection with respect to multiplexing (see Note 2). 


During the resynchronization (see 6.14) and reassignment after 
failure (see 6.12) procedures, a transport entity may reassign a 
transport connection to another network connection joining the 
same NSAPs, provided that it is the owner of the network 
connection and that the transport connection is assigned to only 
one network connection at any given time. 


During the splitting procedure (see 6.23), a transport entity may 
assign a transport connection to any additional network 
connection joining the same NSAPs, provided that it is the owner 
of the network connection and that multiplexing is possible on 
the network connection. 


The responder becomes aware of the assignment when it receives 


a) a CR TPDU during the connection establishment procedure 
(see 6.5); or 


b) an RJ TPDU or a retransmitted CR or DR TPDU during the 
resynchronization (see 6.14) and reassignment after 


failure (see 6.12) procedures; or 


c) any TPDU when splitting (see 6.23) is used. 
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NOTES 


6. 


6. 


2 


Dis 


1 


When a new network connection is created, the quality of 
service requested is a local matter, although it will 
normally be related to the requirements of transport 
connection(s) expected to be assigned to it. 


An existing network connection may also not be suitable 
if, for example, the quality of service requested for the 
transport connection cannot be attained by using or 
enhancing the network connection. 


A network connection with no transport connection(s) 
assigned to ity may be available after initial 
establishment, or because all of the transport connections 
previously assigned to it have been released. It is 
recommended that only the owner of such a network 
connection should release it. Furthermore, it is 
recommended that it not be released immediately after the 
transmission of the final TPDU of a transport connection - 
either a DR TPDU in response to CR TPDU or a DC TPDU in 
response to DR TPDU. An appropriate delay will allow the 
TPDU concerned to reach the other transport entity 
allowing the freeing of any resources associated with the 
transport connection concerned. 


After the failure of a network connection, transport 
connections which were previously multiplexed together may 
be assigned to different network connections, and vice 
versa. 


Transport protocol data unit (TPDU) transfer 


Purpose 


The TPDU transfer procedure is used in all classes to convey 
transport protocol data units in user data fields of network 
service primitives. 
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6.2.2 Network Service Primitives 
The procedure uses the following network service primitives: 
a)  N-DATA; 


b) N-EXPEDITED DATA 


6.2.3 Procedure 


The transport protocol data units (TPDUs) defined for the 
protocol are listed in 4.2. 


When the network expedited variant has been selected for class 1, 
the transport entities shall transmit and receive ED and EA TPDUs 


as NS-user data parameters of N-EXPEDITED DATA primitives. 


In all other cases, transport entities shall transmit and receive 
TPDUs as NS-user data parameters of N-DATA primitives. 


When a TPDU is put into an NS-user data parameter, the 
Significance of the bits within an octet and the order of octets 


within a TPDU shall be as defined in 13.2. 


NOTE - TPDUs may be concatenated (see 6.4). 


6.3 Segmenting and reassembling 
6.3.1 Purpose 


The segmenting and reassembling procedure is used in all classes 
to map TSDUs onto TPDUs. 
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6.3.2 TPDUs and parameter used 
The procedure makes use of the following TPDU and parameter: 
DT TPDUs; 


- End of TSDU. 


6.3.3 Procedure 


A transport entity shall map a TSDU on to an ordered sequence of 
one or more DT TPDUs. This sequence shall not be interrupted by 
other DT TPDUs on the same transport connection. 


All DT TPDUs except the last DT TPDU in a sequence greater than 
one shall have a length of data greater than zero. 


NOTES 


1. The EOT parameter of a DT TPDU indicates whether or not 
there are subsequent DT TPDUs in the sequence. 


2. There is no requirement that the DT TPDUs shall be of the 
maximum length selected during connection establishment. 


6.4 Concatenation and separation 


6.4.1 Purpose 


The procedure for concatenation and separation is used in classes 
1, 2, 3 and 4 to convey multiple TPDUs in one NSDU. 
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6. 
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Procedure 


A transport entity may concatenate TPDUs from the same or 
different transport connections. 


The set of concatenated TPDUs may contain: 


a) 


NOTES 


6. 


6. 


5 


te 
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any number of TPDUs from the following list: AK, EA, RJ, 
ER, DC TPDUs, provided that these TPDUS come from 
different transport connections; 


no more than one TPDU from the following list: CR, DR, 
CG; DT, ED TPDUs; if this TPDU is present, it shall be 
placed last in the set of concatenated TPDUs. 


The TPDUs within a concatenated set may be distinguished 
by means of the length indicator parameter. 


The end of a TPDU containing data is indicated by the 
termination of the NSDU. 


The number of concatenated TPDUs referred to in 6.4.2.a is 
bounded by the maximum number of transport connections 
which are multiplexed together except during assignment or 
reassignment. 


Connection establishment 


Purpose 


The procedure for connection establishment is used in all classes 
to create a new transport connection. 
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6.5.2 Network service primitives 
The procedure uses the following network service primitive: 


N-DATA 


6.5.3 TPDUs and parameters used 
The procedure uses the following TPDUs and parameters: 
a) CR TPDU; 
=r CDT; 


- DST-REF (set to zero); 
— SRC-REF 


- CLASS and OPTIONS (i.e. preferred class, use of extended 
format, non-use of explicit flow control in class 2); 


- Calling TSAP-ID; 

- called TSAP-ID; 

- TPDU size (proposed); 

- version number; 

- security parameter; 

- checksum; 

- additional option selection (i.e. use of 


expedited in class 1, use of receipt confirmation in 


class. dy non-use of checksum in class 4, 
transport expedited data transfer service); 

- alternative protocol class (es); 

- acknowledge time; 

- throughput (proposed); 

- residual error rate (proposed); 

- priority (proposed); 

- transit delay (proposed); 

- reassignment time; 

- user data. 


b) CC TPDU; 


= CDRs 
— DST-REF; 
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=- SRC-REF; 

- CLASS and OPTIONS (selected); 

- calling TSAP-ID; 

- called TSAP-ID; 

- TPDU size (selected); 

- security parameter; 

- checksum; 

- additional option selection (selected); 
- acknowledge time; 

- throughput (selected); 

- residual error rate (selected); 
- priority (selected); 

- transit delay (selected); 

- user data. 


NOTE - The transport service defines transit delay as 
requiring a previously stated average TSDU size as a basis 
for any specification. This protocol, as specified in 
13.3.4(n), uses a value of 128 octets. Conversion to and 
from specifications based upon some other value is a local 
matter. 


6.5.4 Procedure 

A transport connection is established by means of one transport 
entity (the initiator) transmitting a CR TPDU to the other 
transport entity (the responder), which replies with a CC TPDU. 


Before sending the CR TPDU, the initiator assigns the transport 


connection being created to one (or more if the splitting 
procedure is being use) network connection(s). It is this set of 
network connections over which the TPDUs are sent. During this 


exchange, all information and parameters needed for the transport 
entities to operate shall be exchanged or negotiated. 


NOTE - Except in class 4, it is recommended that the 
initiator starts an optional timer TS1 at the time the CR 


TPDU is sent. This timer should be stopped when the 
connection is considered as accepted or refused or 
unsuccessful. If the timer expires, the initiator should 
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reset or disconnect the network connection and, in classes 1 


and 3 freeze the reference (see 6.18). For all other 
transport connection(s) multiplexed on the same network 
connection the procedures for reset or disconnect as 


appropriate should be followed. 


After receiving the CC TPDU for a class which ¡includes the 
procedure for retention until acknowledgement of TPDUs the 
initiator shall acknowledge the CC TPDU as defined in table 5 
(see 6.13). 


When the network expedited variant of the expedited data transfer 
(see 6.11) has been agreed (possible in class 1 only), the 
responder shall not send an ED TPDU before the CC TPDU is 
acknowledged. 


The following information is exchanged: 

a) references. Each transport entity chooses a reference 
which is to be used by the peer entity is 16 bits long and 
which is arbitrary except for the following restrictions: 
1) it shall not already be in use or frozen (see 6.18), 
2) it shall not be zero. 

This mechanism is symmetrical and provides identification 
of the transport connection independent of the network 


connection. The range of references used for transport 
connections, in a given transport entity, is a local 


matter. 
b) addresses (optional). Indicate the calling and called 
transport service access points. When either network 


address unambiguously defines the transport address this 
information may be omitted. 


c) initial credit. Only relevant for classes which include 
the explicit flow control function. 


d) user data. Not available if Class 0 is the preferred 
class (see note). Up to 32 octets in other classes. 
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NOTE - If class 0 is a valid response according to table 
3, inclusion of user data in the CR TPDU may cause the 
responding entity to refuse the connection (e.g. if it 
only supports class 0). 

e) acknowledgement time. Only in class 4. 


f) checksum parameter. Only in class 4. 


g) security parameter. This parameter and its semantics are 
user defined. 


The following negotiations take place: 


h) protocol class. The initiator shall propose a preferred 
class and may propose any number of alternative class 
which permit a valid response as defined in table 3. The 


initiator should assume when it sends the CR TPDU that its 
preferred class will be agreed to, and commence the 
procedures associated with that class, except that if 
class 0 or class 1 is an alternative class, multiplexing 
shall not commence until a CC TPDU selecting the use of 
classes 2, 3 or 4 has been received. 


NOTE - This means, for example, that when the preferred 
class includes resynchronization (see 6.14) the 
resynchronization will occur if a reset is signalled 
during connection establishment. 


The responder shall select one class defined in table 3 as a 
valid response corresponding to the preferred class and to the 
class(es), if any, contained in the alternative class parameter 
of the CR TPDU. It shall indicate the selected class in the CC 
TPDU and shall follow the procedures for the selected class. 


If the preferred class is not selected, then on receipt of the CC 
TPDU the initiator shall adjust its operation according the 
procedures of the selected class. 
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| Pre- | Alternative class 

| ferred |---------------------------------------------------- | 
[class | 0 | 1 | 2 | 3 | 4 | none | 
------- | oo |--------|--------| --------| --------| ------- 
| 0 [not [not [not [not [not [class | 
| valid valid valid valid valid | 0 

| 1 |class |class [not [not [not [class | 
| |1 oro |1 or 0 [valid |valid |valid (Lor 0 | 
|| -- |--------]-------- | | | > 

| 2 |class [not [class [not [not [class | 
| É or 0 a 2 valid valid 2 

| 3 |class |class 3,|class [class [not [class | 
| |3,2 or 0|2,1 or 0|3 or 2 |3 or 2 [valia [l3 or2 | 
|-------|-------- |--------|-------- |--------|--------|------- 

| 4 [class lclass 4, [class [class [class [class | 
| [4,2 or 0251 or 0/4 er -2 [4,3 or 214 or 2 |4 or 2 | 
a a A SaaS ea ae See + 


Table 3. 


Valid responses corresponding to the preferred class and any 
alternative class proposed in the CR TPDU 


NOTES: 
1. The valid responses indicated in table 3 result from both 


explicit negotiation, whereby each of the classes proposed 
is a valid response, and implicit negotiation whereby: 


a) if class 3 or 4 is proposed then class 2 is a valid 
response; 

b) if class 1 is proposed then class 0 is a valid 
response. 
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Negotiation from class 2 to class 1 and from any class to 
an higher-numbered class is not valid. 


Redundant combinations are not a protocol error. 


TPDU size. The initiator may propose a maximum size for 
TPDUs, and the responder may accept this value or respond 
with any value between 128 and the proposed value in the 
set of values available (see 13.3.4.b). 


NOTE - The length of the CR TPDU does not exceed 128 
octets (see 13.3). 


normal or extended format. Either normal or extended is 
available. When extended is used this applies to CDT, 
TPDU-NR, ED-TPDU-NR, YR-TU-NR and YR-EDTU-NR parameters. 


checksum selection. This defines whether or not TPDUs of 
the connection are to include a checksum. 


quality of service parameters. This defines the 
throughput, transit delay, priority and residual error 
rate. 


the non-use of explicit flow control in class 2. 


the use of network receipt confirmation and network 
expedited when class 1 is to be used. 


use of expedited data transfer service. This allows both 
TS-users to negotiate the use or non-use of the expedited 
data transport service as defined in the transport service 
(ISO 8072). 


The following information is sent only in the CR TPDU: 


s) 


version number. This defines the version of the transport 
protocol standard used for this connection. 


reassignment time parameter. This indicates the time for 


which the initiator will persist in following the 
reassignment after failure procedure. 
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The negotiation rules for the options are such that the initiator 
may propose either to use or not to use the option. The 
responder may either accept the proposed choice or select an 
alternative choice as defined in table 4. 


In class 2, whenever a transport entity requests or agrees to the 
transport expedited data transfer service or to the use of 
extended formats, it shall also request or agree (respectively) 
to the use of explicit flow control. 


| Option | Proposal Made | Valid Selection | 
by the Responder 


|Transport expedited | Yes | Yes or No 
|data transfer service | No | No 
| (Classes 1,2,3,4 only) | | | 


Use of receipt confir- Yes Yes or No 
mation (Class 1 only) No No 
| | O | a a | 
|Use of the network | Yes | Yes or No 
lexpedited variant | No | No 

| (Class 1 only) | | | 
Non-use of checksum | Yes | Yes or No 

| (Class 4 only) | No | No | 
e |--------=--------- | ORE | 
|Non-use of explicit | Yes | Yes or No 

| flow control | No | No | 
fue 2 only) | | | 
|Use of extended format | Yes | Yes or No 

| (Classes 2,3,4 only) | No | No 
E A A ET al + 


Table 4. Negotiation of options during connection establishment 
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NOTE - Table 4 defines the procedures for negotiation of options. 
This negotiation has been designed such that if the initiator 
proposes the mandatory implementation option specified in clause 
14, the responder has to accept use of this option over the 
transport connection except for the use of the transport 
expedited data transfer service which may be rejected by the TS- 
user. If the initiator proposes a non-mandatory implementation 
option, the responder is entitled to select use of the mandatory 
implementation option for use over the transport connection. 


6.6 Connection refusal 
6.6.1 Purpose 
The connection refusal procedure is used in all classes when a 


transport entity refuses a transport connection in response to a 
CR TPDU. 


6.6.2 TPDUs and parameters used 


The procedure makes use of the following TPDUs and parameters: 


a) DR TPDU; 
— SRC-REF; 
- reason; 
- user data. 


b) ER TPDU; 


- reject code; 
- rejected TPDU parameter. 
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6.6.3 Procedure 


If a transport connection cannot be accepted, the responder shall 
respond to the CR TPDU with a DR TPDU. The reason shall indicate 
why the connection was not accepted. The source reference field 
in the DR TPDU shall be set to zero to indicate an unassigned 
reference. 


If a DR TPDU is received the initiator shall regard the 
connection as released. 


The responder shall respond to an invalid CR TPDU by sending an 

ER or DR TPDU. If an ER TPDU is received in response to a CR 

TPDU, the initiator shall regard the connection as released. 

NOTES 

1. When the invalid CR TPDU can be identified as having class 0 
as the preferred class, it is recommended to respond with an 
ER TPDU. For all other invalid CR TPDUs either an ER TPDU or 
DR TPDU may be sent. 

2. If the optimal supervisory timer TS1 has been set for this 


connection then the entity should stop the timer on receipt 
of the DR or ER TPDU. 


6.7 Normal release 
6.7.1 Purpose 


The release procedure is used by a transport entity in order to 


terminate a transport connection. The implicit variant is used 
only in class 0. The explicit variant is used in classes 1,2,3 
and 4. 
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NOTES 


1. When the implicit variant is used (i.e. in class 0), the 
lifetime of the transport connection is directly correlated 
with the lifetime of the network connection. 


2. The use of the explicit variant of the release procedure 
enables the transport connection to be released independently 
of the underlying network connection. 


6.7.2 Network service primitives 


The procedure makes use of the following network service 
primitives: 


a) N-DISCONNECT (implicit variant only), 


b) N-DATA 


6.7.3 TPDUs and parameters used 
The procedure makes use of the following TPDUs and parameters: 
a) DR TPDU; 
- clearing reason; 
- user data; 
- SRC-REF; 
- DST-REF. 


b) DC TPDU. 
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6.7.4 Procedure for implicit variant 


In the implicit variant either transport entity disconnects a 
transport connection by disconnecting the network connection to 
which it is assigned. When a transport entity receives an N- 
DISCONNECT this should be considered as the release of the 
transport connection. 


6.7.5 Procedure for explicit variant 


When the release of a transport connection is to be initiated a 
transport entity 


a) if it has previously sent or received a CC TPDU (see note 
Lys shall send a DR TPDU. It shall ignore all 
subsequently received TPDUs other than a DR or DC TPDU. 
On receipt of a DR or DC TPDU it shall consider the 
transport connection released; 


b) in other cases it shall: 
1) For classes other than class 4 wait for the 


acknowledgement of the outstanding CR TPDU; if it 
receives a CC TPDU, it shall follow the procedures in 


6.7.5.a. 

2) For class 4 either send a DR TPDU with a zero value in 
the DST-REF field or follow the procedure in 
T A Ds die 


A transport entity that receives a DR TPDU shall 


c) if it has previously sent a DR TPDU for the same transport 
connection, consider the transport connection released; 


d) if it has previously sent a CR TPDU that has not been 


acknowledged by a CC TPDU, consider the connection refused 
(see 6.6). 
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e) 


in other cases, send a DC TPDU and consider the transport 
connection released. 


NOTES 


1) 


This requirement ensures that the transport entity is 
aware of the remote reference for the transport 
connection. 


When the transport connection is considered as released 
the local reference is either available for re-use or is 
frozen (see 6.18). 


After the release of a transport connection the network 
connection can be released or retained to enable its re- 
use for the assignment of other transport connections (see 
Slides 


Except in class 4, it is recommended that, if a transport 
entity does not receive acknowledgement of a DR TPDU 
within time TS2, it should either reset or disconnect the 
network connection, and freeze the reference when 
appropriate (see 6.18). For all other transport 
connection(s) multiplexed on this network connection the 
procedures for reset or disconnect as appropriate should 
be followed. 


When a transport entity is waiting for a CC TPDU before 
sending a DR TPDU and the network connection is reset or 
released, it should consider the transport connection 
released and, in classes other than classes 0 and 2, 
freeze the reference (see 6.18). 


Error Release 
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6.8.1 Purpose 
This procedure is used only in classes 0 and 2 to release a 


transport connection on the receipt of an N-DISCONNECT or N-RESET 
indication. 


6.8.2 Network service primitives 
The procedure makes use of the following service primitives: 
a) N-DISCONNECT indication; 


b) N-RESET indication. 


6.8.3 Procedure 


When, on the network connection to which a transport connection 
is assigned, an N-DISCONNECT or N-RESET indication is received, 
both transport entities shall consider that the transport 
connection is released and so inform the TS-users. 


NOTE - In other classes, since error recovery is used, the 


receipt of an N-RESET indication or N-DISCONNECT indication will 
result in the invocation of the error recovery procedure. 


6.9 Association of TPDUs with transport connections 
6.9.1 Purpose 
This procedure is used in all classes to interpret a received 


NSDU as TPDU(s) and, if possible, to associate each such TPDU 
with a transport connection. 
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6.9.2 Network service primitives 


This ¡procedure makes use of the following network service 
primitives: 


a) N-DATA indication; 


b) N-EXPEDITED DATA indication. 


6.9.3 TPDUs and parameters uses 
This procedure makes use of the following TPDUs and parameters: 


a) any TPDU except CR TPDU, DT TPDU in classes 0 or 1 and AK 
TPDU in class 1; 


- DST-REF 
b) CR, CC, DR and DC TPDUs; 
— SCR-REF. 


c) DT TPDU in classes 0 or 1 and AK TPDU in class 1. 


6.9.4 Procedures 

6.9.4.1 Identification of TPDUs 

If the received NSDU or Expedited NSDU cannot be decoded (i.e. 
does not contain one or more correct TPDUs) or is corrupted (i.e. 


contains a TPDU with a wrong checksum) then the transport entity 
shall: 
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a) if the network connection on which the error is detected 
has a class 0 or class 1 transport connection assigned to 
it, then treat as a protocol error (see 6.22) for that 
transport connection; 


b) otherwise 


1) if the NSDU can be decoded but contains corrupted 
TPDUs, ignore the TPDUs (class 4 only) and optionally 
apply 6.9.4.b.2. 


2) if the NSDU cannot be decoded issue an N-RESET or N- 
DISCONNECT request for the network connection and for 
all the transport connections assigned to this network 
connection (if any), apply the procedures defined for 
handling of network signalled reset or disconnect. 


If the NSDU can be decoded and is not corrupted, the 
transport entity shall: 


c) if the network connection on which the NSDU was received 
has a class 0 transport connection assigned to it, then 
consider the NSDU as forming TPDU and associate the TPDU 
with the transport connection (see 6.9.4.2). 


d) otherwise, invoke the separation procedures and for each 
of the individual TPDUs in the order in which they appear 
in the NSDU apply the procedure defined in 6.9.4.2. 


6.9.4.2 Association of individual TPDUs 


If the received TPDU is a CR TPDU then, if it is a duplicate, as 
recognized by using the NSAPs of the network connection, and the 
SRC-REF parameter, then it is associated with the transport 
connection created by the original value of the CR TPDU; 
otherwise it is processed as requesting the creation of a new 
transport connection. 


If the received TPDU is a DT TPDU and the network connection has 
a class 0 or 1 transport connection assigned to it, or an AK TPDU 
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where a class 1 transport connection is assigned, then the TPDU 
is associated with the transport connection. 


Otherwise, the DST-REF parameter of the TPDU is used to identify 
the transport connection. The following cases are distinguished: 


a) 


if the DST-REF is not allocated to a transport connection, 
the transport entity shall respond on the same network 
connection with a DR TPDU if the TPDU is a CC TPDU, with a 
DC TPDU if the TPDU is a DR TPDU and shall ignore the TPDU 
if neither a DR TPDU nor CC TPDU. No association with a 
transport connection is made. 


if the DST-REF is allocated to a connection, but the TPDU 
is received on a network connection to which the 
connection has not been assigned then there are three 
cases: 


1) if the transport connection is of class 4 and if the 
TPDU is received on a network connection with the same 
pair of NSAPs as that of the CR TPDU then the TPDU is 
considered as performing assignment, 


2) if the transport connection is not assigned to any 
network connection (waiting for reassignment after 
failure) and if the TPDU is received on a network 
connection with the same pair of NSAPs as that of the 
CR TPDU then the association with that transport 
connection is made. 


3) Otherwise, the TPDU is considered as having a DST-REF 
not allocated to a transport connection (case a). 


If the TPDU is a DC TPDU then it is associated with the 
transport connection to which the DST-REF is allocated, 
unless the SRC-REF is not the expected one, in which case 
the DC TPDU is ignored. 


If the TPDU is a DR TPDU then there are three cases: 
1) if the SRC-REF is not as expected then a DC TPDU with 


DST-REF equal to the SRC-REF of the received DR TPDU 
is sent back and no association is made; 
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6.10 D 


6.10.1 


Data TP 
non-use 


2) if a CR TPDU is unacknowledged then the DR TPDU is 
associated with the transport connection, regardless 
of the value of its SRC-REF parameter; 


3) otherwise, the DR TPDU is associated with the 
transport connection identified by the DST-REF 
parameter. 


if the TPDU is a CC TPDU whose DST-REF parameter 
identifies an open connection (one for which a CC TPDU has 
been previously received), and the SRC-REF in the CC TPDU 
does not match the remote reference, then a DR TPDU is 
sent back with DST-REF equal to the SRC-REF of the 
received CC TPDU and no association is made. 


if none of the above cases apply then the TPDU is 
associated with the transport connection identified by the 
DST-REF parameter. 


ata TPDU numbering 
Purpose 


DU numbering is used in classes 1, 2 (except when the 
of explicit flow control option is selected), 3 and 4. 


Its purpose is to enable the use of recovery, flow control and 
re-sequencing functions. 


6.10.2 


TPDUs and parameters used 


The procedure makes use of the following TPDU and parameter: 


DT TPDU; 


= TR 


DU-NR. 
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6.10.3 Procedure 


A Transport entity shall allocate the sequence number zero to the 
TPDU-NR of the first DT TPDU which it transmits for a transport 
connection. For subsequent DT TPDUs sent on the same transport 
connection, the transport entity shall allocate a sequence number 
one greater than the previous one. 


When a DT TPDU is retransmitted, the TPDU-NR parameter shall have 
the same value as in the first transmission of that DT TPDU. 


Modulo 2**7 arithmetic shall be used when normal formats have 
been selected and modulo 2**31 arithmetic shall be used when 
extended formats have been selected. In this International 
Standard the relationships 'greater than’ and ’less than’ apply 
to a set of contiguous TPDU numbers whose range is less than the 
modulus and whose starting and finishing numbers are known. The 
term ‘less than’ means ’occurring sooner in the window sequence’ 
and the term 'greater than’ means ’occurring later in the window 
sequence’. 


6.11 Expedited data transfer 

6.11.1 Purpose 

Expedited data transfer procedures are selected during connection 
establishment. The network normal data variant may be used in 


classes 1, 2, 3 and 4. The network expedited variant is only 
used in class 1. 


6.11.2 Network service primitives 


The ¡procedure makes use of the following network service 
primitives: 


a) N-DATA; 
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b) N-EXPEDITED DATA. 


6.11.3 TPDUs and parameter used 
The procedure makes use of the following TPDUs and parameters: 
a) ED TPDU; 
- ED TPDU-NR. 
b) EA TPDU; 


— YR-EDTU-NR. 


6.11.4 Procedures 


The TS-user data parameter of each T-EXPEDITED DATA request shall 
be conveyed as the data field of an Expedited Data (ED) TPDU. 


Each ED TPDU received shall be acknowledged by an Expedited 
Acknowledge (EA) TPDU. 


No more than one ED TPDU shall remain unacknowledged at any time 
for each direction of a transport connection. 


An ED TPDU with a zero length data field is a protocol error. 


ol 


NOTES 


1. The network normal data variant is used, except when the 
network expedited variant (available in Class 1 only), has 
been agreed, in which case ED and EA TPDUs are conveyed in 
the data fields of N-EXPEDITED DATA primitives (see 
6.2.3). 


2. No TPDUs can be transmitted using network expedited until 
the CC TPDU becomes acknowledged, to prevent the network 
expedited from overtaking the CC TPDU. 


6.12 Reassignment after failure 
6.12.1 Purpose 


The reassignment after failure procedure is used in Classes 1 and 
3 to commence recovery from an NS-provider signalled disconnect. 


6.12.2 Network service primitives 
The procedure uses the following network service primitive: 


N-DISCONNECT indication 


6.12.3 Procedure 
When an N-DISCONNECT indication is received from the network 
connection to which a transport connection is assigned, the 


initiator shall apply one of the following alternatives: 


a) if the TTR timer has not already run out and no DR TPDU is 
retained then: 
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1) assign the transport connection to a different network 
connection (see 6.1) and start its TTR timer if not 
already started. 


2) while waiting for the completion of assignment if: 


- an N-DISCONNECT indication is received, repeat the 
procedure from 6.12.3.a, 


- the TTR timer expires, begin procedure 6.12.3.b. 


3) when reassignment is completed, begin 
resynchronization (see 6.14) and: 


- if a valid TPDU is received as the result of the 
resynchronization, stop the TTR timer, or 


— if TTR runs out, wait for the next event, or 


- if an N-DISCONNECT indication is received, then 
begin either procedure 6.12.3.a er 6.12.3.b 
depending on the TTR timer. 


NOTE - After the TTR timer expires and while waiting for 
the next event, it is recommended that the initiator 
starts the TWR timer. If the TWR timer expires before the 
next event the initiator should begin the procedure in 


6:12.3.b. 

b) if the TTR timer has run out, consider the transport 
connection as released and freeze the reference (see 
6.18). 

Cc) if a DR TPDU is retained and the TTR timer has not run 
out, then follow the actions in either 6.12.3.a or 
Gn 223.3 e 


The responder shall start its TWR timer if not already started. 
The arrival of the first TPDU related to the transport connection 
(because of resynchronization by the initiator) completes the 
reassignment after failure procedure. The TWR timer is stopped 
and the responder shall continue with resynchronization (see 
6.14). If reassignment does not take place within this time, the 
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transport connection is considered released and the reference is 
frozen (see 6.18). 


6.12.4 Timers 
The reassignment after failure procedure uses two timers: 
a) TTR, the time to try reassignment/resynchronization timer; 


b) TWR, the time to wait for reassignment/resynchronization 
timer. 


The TTR timer is used by the initiator. Its value shall not 
exceed two minutes minus the sum of the maximum disconnect 
propagation delay and the transit delay of the network 
connections (see note 1). The value for the TTR timer may be 
indicated in the CR TPDU. 


The TWR timer is used by the responder. If the reassignment time 
parameter is present in the CR TPDU, the TWR timer value shall be 
greater than the sum of the TTR timer plus the maximum disconnect 
propagation delay plus the transit delay of the network 
connections. 


If the reassignment time parameter is not present in the CR TPDU, 
a default value of 2 minutes shall be used for the TWR timer. 


NOTES 
1. Provided that the required quality of service is met, TTR may 
be set to zero (i.e. no assignment). This may be done, for 


example, if the rate of NS-provider generated disconnects is 
very low. 


2. Inclusion of the reassignment time parameter in the CR TPDU 
allows the responder to use a TWR value of less than 2 
minutes. 


3. If the optional TS1 and TS2 timers are used, it is 
recommended: 
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to stop TS1 or TS2 if running when TTR or TWR is 
started; 


to restart TS1 or TS2 if necessary when the 
corresponding TPDU (CR TPDU or DR TPDU respectively is 


repeated) ; 


to select for TS1 and TS2 values greater than TTR. 
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6.13 Retention until acknowledgement of TPDUs 

6.13.1 Purpose 

The retention until acknowledgement of TPDUs procedure is used in 
classes 1, 3 and 4 to enable and minimize retransmission after 


possible loss of TPDUs. 


The confirmation of receipt variant is used only in Class 1 when 
it has been agreed during connection establishment (see note). 


The AK variant is used in classes 3 and 4 and also in Class 1 
when the confirmation of receipt variant has not been agreed 
during connection establishment. 

NOTE - Use of confirmation of receipt variant depends on the 


availability of the network layer receipt confirmation service 
and the expected cost reduction. 


6.13.2 Network service primitives 
The procedure uses the following network service primitives: 
a) N-DATA; 


b) N-DATA ACKNOWLEDGE. 


6.13.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 
a) CR, CC, DR and DC TPDUs; 
b) RJ and AK TPDUs; 


- YR-TU-NR. 
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c) DT TPDU; 
— TPDU-NR. 
d) ED TPDU; 
- ED-TPDU-NR. 
e) EA TPDU; 


— YR-EDTU-NR. 


6.13.4 Procedures 


Copies of the following TPDUs shall be retained upon transmission 
to permit their later retransmission: 


CR, CC, DR, DT and ED TPDUs 


except that if a DR is sent in response to a CR TPDU there is no 
need to retain a copy of the DR TPDU. 


In the confirmation of receipt variant, applicable only in Class 
1, transport entities receiving N-DATA indications which convey 
DT TPDUs and have the confirmation request field set shall issue 
an N-DATA ACKNOWLEDGE request (see notes 1 and 2). 


After each TPDU is acknowledged, as shown in table 5, the copy 


need not be retained. Copies may also be discarded when the 
transport connection is released. 
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NOTES 


It is a local matter for each transport entity to decide 
which N-DATA requests should have the confirmation request 
parameter set. This decision will normally be related to 
the amount of storage available for retained copies of the 


DT TPDUs. 


Use of the confirmation request parameter may affect the 
quality of network service. 
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TPDU 


CC 


DT 


DT 


ED 


VARIANT | RETAINED UNTIL ACKNOWLEDGED BY | 
both |CC, DR or ER TPDU. | 
both de or DR (in case of collision) TPDU. | 
confirmation |N -DATA Acknowledge indication, RJ, | 
of receipt |DT, EA or ED TPDU. | 
variant | | 
AK variant jos DT, AK, ED or EA TPDU. | 
confirmation |N- DATA ACKNOWLEDGE indication cor- | 
of receipt | responding to an N-DATA request which | 
variant |conveyed, or came after, the DT TPDU. | 
AK variant AK or RJ TPDU for which the YR-TU-NR 

is greater than TPDU-NR in the DT 

| TPDU. | 
both |EA TPDU for which the YR-EDTU-NR is | 

|equal to the ED-TPDU-NR in the | 

|ED TPDU. | 


Table 5. Acknowledgement of TPDUs 
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6.14 Resynchronization 
6.14.1 Purpose 
The resynchronization procedures are used in Classes 1 and 3 to 


restore the transport connection to normal after a reset or 
during reassignment after failure according to 6.12. 


6.14.2 Network service primitives 


The procedure makes use of the following network service 
primitive: 


N-RESET indication. 


6.14.3 TPDUs and parameters used 
The procedure uses the following TPDUs and parameters: 
a) CR, DR, CC and DC TPDUs 
b) RJ TPDUs; 
— YR-TU-NR. 
c) DT TPDU; 
- TPDU-NR 
d) ED TPDU; 
- ED TPDU-NR. 
e) EA TPDU; 


— YR-EDTU-NR. 
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6.14.4 Procedure 


A transport entity which is notified of the occurence of an N- 
RESET or which is performing ‘’reassignment after failure’ 
according to 6.12 shall carry out the active resynchronization 
procedure (see 6.14.4.1) unless any of the following hold: 


a) the transport entity is the responder (see note). In this 
case the passive resynchronization procedure is carried 
out (see 6.14.4.2). 


b) the transport entity has elected not to reassign (see 
6.12.3.c). In this case no resynchronization takes place. 


6.14.4.1 Active resynchronization procedures 


The Transport entity shall carry out one of the following 
actions: 


a) if the TTR timer has been previously started and has run 
out (i.e. no valid TPDU has been received), the transport 
connection is considered as released and the reference is 
frozen (see 6.18). 


b) otherwise, the TTR timer shall be started (unless it is 
already running) and the first applicable of the following 


actions shall be taken: 


1) if a CR TPDU is unacknowledged, then the transport 
entity shall retransmit it; 


2) if a DR TPDU is unacknowledged, then the transport 
entity shall retransmit it; 


3) otherwise, the transport entity shall carry out the 
data resynchronization procedures (6.14.4.3). 


The TTR timer is stopped when a valid TPDU is received. 
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6.14.4.2 Passive resynchronization procedures 


The transport entity shall not send any TPDUs until a TPDU has 
been received. The transport entity shall start its TWR timer if 
it was not already started (due to a previous N-DISCONNECT or N- 
RESET indication). If the timer runs out prior to the receipt of 
a valid TPDU which commence resynchronization (i.e. CR or DR or 
RJ TPDU) the transport connection is considered as released and 
the reference is released (see 6.18). 


When a valid TPDU is received the transport entity shall stop its 
TWR timer and carry out the appropriate one of the following 
actions, depending on the TPDU: 


a) if it is a DR TPDU, then the transport entity shall send a 
DC TPDU; 


b) if it is a repeated CR TPDU (see note 1) then the 
transport entity shall carry out the appropriate action 
from the following: 


1) if a CC TPDU has already been sent, and acknowledged: 
treat as a protocol error; 


2) if a DR TPDU is unacknowledged (whether or not a CC 
TPDU is unacknowledged): retransmit the DR TPDU, but 


setting the source reference to zero; 


3) if the T-CONNECT response has not yet been received 
from the user: take no action; 


4) otherwise; retransmit the CC TPDU followed by an 
unacknowledged ED TPDU (see note 2) and any DT TPDU; 


NOTES 
1. A repeated CR TPDU can be identified by being on a 


network connection with the appropriate network 
addresses and having a correct source reference. 
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2. The transport entity should not use network expedited 
until the CC TPDU is acknowledged (see 6.5). This 
rule prevents the network expedited from overtaking 
the CC TPDU. 


c) if it is an RJ or ED TPDU then one of the following 
actions shall be taken: 


1) if a DR TPDU is unacknowledged, then the transport 
entity shall retransmit it; 


2) otherwise, the transport entity shall carry out the 
data resynchronization procedures (6.14.4.3). 


3) If a CC TPDU was unacknowledge, the RJ or ED TPDU 
should then be considered as acknowledging the CC 


TPDU. If a CC TPDU was never sent, the RJ TPDU should 
then be considered as a protocol error. 


6.14.4.3 Data Resynchronization Procedures 


The transport entity shall carry out the following actions in the 
following order: 


a) (re) transmit any ED TPDU which is unacknowledged, 


b) transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR 
of the next expected DT TPDU; 
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wait for the next TPDU from the other transport entity, 
unless an RJ or DR TPDU has already been received; if a DR 
TPDU is received the transport entity shall send a DC, 


freeze the reference, inform the TS-user of the 
disconnection and take no further action (i.e. it shall 
not follow the procedures in 6.14.4.3.d). If an RJ TPDU 
is received, the procedure of 6.14.4.3.d shall be 
followed. If an ED TPDU is received the procedures as 
described in 6.11 shall be followed. If it is a 


duplicated ED-TPDU the transport entity shall acknowledge 
it, with an EA TPDU, discard the duplicated ED TPDU and 
wait again for the next TPDU. 


(re)transmit any DT TPDUs which are unacknowledged, 
subject to any applicable flow control procedures (see 
note); 


NOTE - The RJ TPDU may have reduced the credit. 


6.15 Multiplexing and demultiplexing 


6.15.1 


Purpose 


The multiplexing and demultiplexing procedures are used in 


Classes 


2, 3 and 4 to allow several transport connections to 


share a network connection at the same time. 


6.£5:52 
The pro 
CC, 


- DS 


TPDUs and parameters used 
cedure makes use of the following TPDUs and parameters: 
DR, DC, DT, AK, ED, EA, RJ and ER TPDUs 


T-REF 
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6.15.3 Procedure 
The transport entities shall be able to send and receive on the 
same network connection TPDUs belonging to different transport 
connections. 
NOTES 
1. When performing demultiplexing the transport connection to 
which the TPDUs apply is determined by the procedures 
defined in 6.9. 
2. Multiplexing allows the concatenation of TPDUs belonging 


to different transport connections to be transferred in 
the same N-DATA primitive (see 6.4). 


6.16 Explicit Flow Control 
6.16.1 Purpose 
The explicit flow control procedure is used in Classes 2, 3 and 4 


to regulate the flow of DT TPDUs independently of the flow 
control in the other layers. 


6.16.2 TPDUs and parameters used 
The procedure makes use of the following TPDUs and parameters: 
a) CR, CC, AK and RJ TPDUs 
= CDT. 
b) DT TPDU 


- TPDU-NR. 
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Cc) AK TPDU 
— YR-TU-NR; 
- subsequence number; 
—- flow control confirmation. 


d) RJ TPDU 


- YR-TU-NR. 


6.16.3 Procedure 


The procedures differ in different classes. They are defined in 
the clauses specifying the separate classes. 


6.17 Checksum 
6.17.1 Purpose 


The checksum procedure is used to detect corruption of TPDUs by 
the NS-provider. 


NOTE - Although a checksum algorithm has to be adapted to the 


type of errors expected on the network connection, at present 
only one algorithm is defined. 


6.17.2 TPDUs and parameters used 
The procedure uses the following TPDUs and parameters: 


All TPDUs 
- checksum 
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6.17.3 Procedure 

The checksum is used only in Class 4. It is always used for the 
CR TPDU, and is used for all other TPDUs except if the non-use of 
the procedure was agreed during connection establishment. 

The sending transport entity shall transmit TPDUs with the 
checksum parameter set such that the following formulas are 
satisfied: 


SUM (from i=1 to i=L) OF a[i] EQUALS <zero> (module 255) 


SUM (from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255) 


where 
T = number (i.e. position) of an octet within the TPDU 
(see 13.2); 
a[i] = value of octet in position 1; 
L = length of TPDU in octets. 


A transport entity which receives a TPDU for a transport 
connection for which the use of checksum has been agreed and 
which does not satisfy the above formulas shall discard the TPDU 
(see also note 2). 


NOTES 

1. An efficient algorithm for determining the checksum 
parameters is given in annex B. 

2. If the checksum is incorrect, it is not possible to know 
with certainty to which transport connection the TPDU is 
related; further action may be taken for all the transport 
connections assigned to the network connection (see 6.9). 

3. The checksum proposed is easy to calculate and so will not 


impose a heavy burden on implementations. However, it 
will not detect insertion or loss of leading or trailing 
zeros and will not detect some octets misordering. 
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6.18 Frozen references 
6.18.1 Purpose 


This procedure is used in order to prevent re-use of a reference 
while TPDUs associated with the old use of the reference may 
still exist. 


6.18.2 Procedure 


When a transport entity determines that a particular connection 
is released it shall place the reference which it has allocated 
to the connection in a frozen state according to the procedures 
of the class. While frozen, the reference shall not be re-used. 


NOTE - The frozen reference procedure is necessary because 
retransmission or misordering can cause TPDUs bearing a reference 
to arrive at an entity after it has released the connection for 
which it allocated the reference. Retransmission, for example, 
can arise when the class includes either resynchronization (see 
6.14) or retransmission on time out (see 6.19). 


6.18.2.1 Procedure for classes 0 and 2 
The frozen reference procedure is never used for these classes. 


NOTE - However for consistency with the other classes freezing 
the references may be done as a local decision. 
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6.18.2.2 Procedure for classes 1 and 3 


The frozen reference procedure is used except in the following 


cases 


a) 


d) 


(see note 1): 


when the transport entity receives a DC TPDU in response 
to a DR TPDU which it has sent (see note 2); 


when the transport entity sends a DR or ER TPDU in 
response to a CR TPDU which it has received (see note 3); 


when the transport entity has considered the connection to 
be released after the expiration of the TWR timer (see 
note 4); 


when the transport entity receives a DR or ER TPDU in 
response to a CR TPDU which it has sent. 


The period of time for which the reference remains frozen shall 
be greater than the TWR time. 


NOTES 


However, even in these cases, for consistency freezing the 
reference may be done as a local decision. 


When the DC TPDU is received it is certain that the other 
transport entity considers the connection released. 


When the DR or ER TPDU is sent the peer transport entity 
has not been informed of any reference assignment and thus 
cannot possibly make use of a reference (this includes the 
case where a CC TPDU was sent, but was lost). 


In 6.18.2.c the transport entity has already effectively 
frozen the reference for an adequate period. 
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6.18.2.3 Procedure for classes 4 
The frozen reference procedure is always used in class 4. The 


period for which the reference remains frozen should be greater 
than L (see 12.2.1.1.6). 


6.19 Retransmission on time-out 
6.19.1 Purpose 


The procedure is used in Class 4 to cope with unsignalled loss of 
TPDUs by the NS-provider. 


6.19.2 TPDUs used 
The procedure makes use of the following TPDUs: 


CR, CC, DR, DT, ED, AK TPDUs. 


6.19.3 Procedure 


The procedure is specified in the procedures for Class 4 (see 
D2 2's A 1 


6.20 Resequencing 
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6.20.1 Purpose 


The resequencing procedure is used in Class 4 to cope 
misordering of TPDUs by the network service provider. 


6.20.2 TPDUs and parameters used 
The procedure uses the following TPDUs and parameters: 


a) DT TPDU; 
— TPDU-NR. 


b) ED TPDU 
- ED TPDU-NR 


6.20.3 Procedure 


The procedure is specified in the procedures for Class 4 
AOS A 


6.21 Inactivity control 
6.21.1 Purpose 


The inactivity control procedure is used in Class 4 to cope 
unsignalled termination of a network connection. 
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with 


(see 


with 


6.21.2 Procedure 


The procedure is specified in the procedures for Class 4 (see 
TDI 


6.22 Treatment of protocol errors 
6.22.1 Purpose 


The procedure for treatment of protocol errors is used in all 
classes to deal with invalid TPDUs. 


6.22.2 TPDUs and parameters used 
The procedure uses the following TPDUs and parameters: 
a) ER TPDU; 
- reject cause; 


- TPDU in error. 


b) DR TPDU; 
- reason code. 


6.22.3 Procedure 

A transport entity that receives a TPDU that can be associated to 
a transport connection and is invalid or constitutes a protocol 
error (see 3.2.16 and 3.2.17) shall take cone of the following 
actions so as not to jeopardize any other transport connections 
not assigned to that network connection: 


a) ignoring the TPDU; 


b) transmitting an ER TPDU; 
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c) resetting or closing the network connection; or 
d) invoking the release procedures appropriate to the class. 
If an ER TPDU is sent in Class 0 it shall contain the octets of 


the invalid TPDU up to and including the octet where the error 
was detected (see notes 3, 4 and 5). 


If the TPDU cannot be associated to a particular transport 
connection then see 6.9. 


NOTES 
1. In general, no further action is specified for the 
receiver of the ER TPDU but it is recommended that it 
initiates the release procedure appropriate to the class. 
If the ER TPDU has been received as an answer to a CR TPDU 
then the connection is regarded as released (see 6.6). 
2. Care should be taken by a transport entity receiving 


several invalid TPDUs or ER TPDUs to avoid looping if the 
error is generated repeatedly. 


3. If the invalid received TPDU is greater than the selected 
maximum TPDU size it is possible that it cannot be 
included in the invalid TPDU parameter of the ER TPDU. 


4. It is recommended that the sender of the ER TPDU starts an 
optional timer TS2 to ensure the release of the 
connection. If the timer expires, the transport entity 
shall initiate the release procedures appropriate to the 
class. The timer should be stopped when a DR TPDU or an 
N-DISCONNECT indication is received. 


5. In classes other than 0, it is recommended that the 
invalid TPDU be also included in the ER TPDU. 
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6.23 Splitting and recombining 
6.23.1 Purpose 


This procedure is used only in class 4 to allow a transport 
connection to make use of multiple network connections to provide 
additional resilience against network failure, to increase 
throughput, or for other reasons. 


6.23.2 Procedure 


When this procedure is being used, a transport connection may be 
assigned (see 6.1) to multiple network connections (see note 1). 
TPDUs for the connection may be sent over any such network 
connection. 


If the use of Class 4 is not accepted by the remote transport 
entity following the negotiation rules, then no network 
connection except that over which the CR TPDU was sent may have 
this transport connection assigned to it. 


NOTES 
1. The resequencing function of Class 4 (see 6.20) is used to 
ensure that TPDUs are processed in the correct sequence. 
2. Either transport entity may assign the connection to 


further network connections of which it is the owner at 
any time during the life of the transport connection. 
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In order to enable the detection of unsignalled network 
connection failures, a transport entity performing 
splitting should ensure that TPDUs are sent at intervals 
on each supporting network connection, for example, by 
sending successive TPDUs on successive network 
connections, where the set of network connections is used 
cyclically. By monitoring each network connection, a 
transport entity may detect unsignalled network connection 
failures, following the inactivity procedures defined in 
TA Die Sin" Thus, for each network connection no period I 
(see 12.2.3.1) may elapse without the receipt of some TPDU 
for some transport connection. 
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7 Protocol Classes 

Table 6 gives an overview of which elements of procedure are 
included in each class. In certain Cases the elements of 
procedure within different classes are not identical and, for 


this reason, table 6 cannot be considered as part of the 
definitive specification of the protocol. 


KEY TO TABLE 6 


+--- | --------------------------------------------------------- + 


O |Negotiable procedure whose implementation in equipment is| 


| 

| |mandatory | 
| 3 

| loptional | 


Negotiable procedure whose implementation in equipment is 
loptional and where use depends on availability within the | 
|network service | 


(1) [Not applicable in class 2 when non-use of explicit flow | 
control is selected | 


(2) [When non use of explicit flow control has been selected, | 
|multiplexing may lead to degradation of quality of | 


| service | 
(3)|This function is provided in class 4 using procedures 
other than those in the cross reference. 
=== S == 2923223 SOS eS SS Se + 
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| [Cross A O 
Protocol Mechanism | refe- Variant | 0| 1| 2| 3| 4 
| rence be tll) all | | 
| ----------------------------- | | ------------ |--|--|--|--|-- 
| Assignment to network Conn. | 6.1 |=| x| x| «| * 
| TPDU Transfer | 6.2 | E BE E 
|-----------------------------|------ |------------ |--|--|--|--|--| 
| Segmenting and Reassembling 6.3 | |x| | x| «| >] 
| ----------------------------- | | > |--|--]--|--|--| 
| Concatenation and Separation| 6.4 | | | *{ x| *[ * 
Connection Establishment 6.5 | | Me IE | Gs) ES 
o | | > |--|--|--|--|-- 
| Connection Refusal | 6.6 | {| *| x| x| >| x 
-<-------------------------—- | | > |--|--|--|--|-- 
| Normal Release | 6.7 implicit | *| | | 
| explicit | | ER A AE 
| Error Release 6.8 pel | *{ | 
| ----------------------------- | | ------------ |--|--|--|--|-- 
| Association of TPDUs with ć | | O PO 
| Transport Connection 6.9 | |x| | x| «| | 
Si A A AAA A ARS pa PA | — == 
| DT TPDU Numbering 6.10 normal | | *Iim(1)m| m 
| extended | O Ro E a ol 
| -----------------------------| ------| ------------ |--|--|--|--|-- 
Expedited Data Transfer | 6.11 | network PA Ml 
| normal | | m| (1) * | x 
network 
expedited ao 
| ----------------------------- | | > |--|--|--|--|--| 
| Reassignment after failure | 6.12 | pl 113) 
A O O O E + 


Table 6. (First of 2 pages) Allocation of procedures within classes 
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| Retention until Acknowledge- [Conf .Receipt] |[ao| | | 
| ment of TPDUs 6.13 |AK | | mi | * 
| Resynchronisation 6.14 | s *| (3) 
(o A A cae [EAS ai be 22185 
Multiplexing and | | FAN des i 
Demultiplexing | 6.15 | | | x * | K 
Spe ere ee A ental SS aca Paarl al Gx 
| Explicit Flow Control With | 6.16 | | | m 2a) | E 
| Without | | aa od MO | 
| Checksum (use of) 6.17 | I, 2) sil el m 
| (non-use of) | =| =| *| *| o 
(eee ae eee eee 9 = tego eee eee ee jeslEaes[es 
| Frozen References | 6.18 | Waa Uae] 
Retransmission on Timeout | 6.19 | | | | | iS 
A ae a sai ais tl ia cds | 
| Resequencing | 6.20 | E IN A * | 
ERE as ¡RAS ¡»ase asad tad [52 
Inactivity Control | 6.21 | he IA TO TA VE 
Treatment of Protocol Errors| 6.22 | AD] iaoa Ae Mo | Rs 
[Serpe ee re A A paje aca a ia 
| Splitting and Recombining | 6.23 Lr ih <a? ye Mae 
Fn O O a + 
Table 6. (2nd of 2 pages) Allocation of procedures within classes 
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8 SPECIFICATION FOR CLASS 0. SIMPLE CLASS 

8.1 Functions of class 0 

Class 0 is designed to have minimum functionality. It provides 
only the functions needed for connection establishment with 
negotiation, data transfer with segmenting and protocol error 
reporting. 

Class 0 provides transport connections with flow control based on 


the network service provided flow control, and disconnection 
based on the network service disconnection. 


8.2 Procedures for class 0 

8.2.1 Procedures applicable at all times 

The transport entities shall use the following procedures: 
a) TPDU transfer (see 6.2); 
b) association of TPDUs with transport connections (see 6.9); 
c) treatment of protocol errors (see 6.22); 


d) error release (see 6.8). 


8.2.2 Connection establishment 
The transport entities shall use the following procedures: 
a) assignment to network connection (see 6.1); then 


b) connection establishment (see 6.5) and, if appropriate, 
connection refusal (see 6.6); 


subject to the following constraints: 
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c) the CR and CC TPDUs shall contain no parameter field other 
than those for TSAP-ID and maximum TPDU size; 


d) the CR and CC TPDUs shall not contain a data field. 


8.2.3 Data transfer 


The transport entities shall use the segmenting and reassembling 
procedure (see 6.3). 


8.2.4 Release 


The transport entities shall use the implicit variant of the 
normal release procedure (see 6.7). 


NOTE - the lifetime of the transport connection is directly 
correlated with the lifetime of the network connection. 
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9 SPECIFICATION FOR CLASS 1: 
9.1 Functions of Class 1 


Class 1 provides transport connections with flow 


the network service provided flow control, 

expedited data transfer, disconnection, and also 
support consecutive transport connections 

connection. 


This class provides the functionality of Class 0 
to recover after a failure signalled by the 
without involving the TS-user. 


9.2 Procedures for Class 1 


9.2.1 Procedures applicable at all times 


BASIC ERROR RECOVERY CLASS 


control based on 


error recovery, 
the ability to 
on a network 


plus the ability 
Network Service, 


The transport entities shall use the following procedures: 


a) TPDU transfer (see 6.2); 

b) association of TPDU with transport connections (see 6.9); 

c) treatment of protocol errors (see 6.22); 

d) reassignment after failure (see 6.12); 

e) resynchronization (see 6.14), or reassignment after 
failure (see 6.12) together with resynchronization (see 
6.14); 

f) concatenation and separation (see 6.4); 

g) retention until acknowledgement of TPDU (see 6.13); the 
variant used, AK or confirmation of receipt, shall be as 
selected during connection establishment (see notes); 

h) frozen references (see 6.18). 
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NOTES 


9.2.2 


The negotiation of the variant of retention until 
acknowledgement of TPDUS procedure to be used over the 
transport connection has been designed such that if the 
initiator proposes the use of the AK variant (i.e. the 
mandatory implementation option), the responder has to 
accept use of this option and if the initiator proposes 
use of the confirmation of receipt variant the responder 
is entitled to select use of the AK variant. 


The AK variant makes use of AK TPDUs to release copies of 
retained DT TPDUs. The CDT parameter of AK TPDUs in class 
1 is not significant, and is set to 1111. 


The confirmation of receipt variant is restricted to this 
class and its use depends on the availability of the 
network layer receipt confirmation service, and the 
expected cost reduction. 


Connection establishment 


The transport entities shall use the following procedures: 


a) 


b) 


9.2.3 


9.26301 


assignment to network connection (see 6.1); then 


connection establishment (see 6.5) and, if appropriate, 
connection refusal (see 6.6). 


Data Transfer 


General 


The sending transport entity shall use the following procedures; 


a) 


segmenting (see 6.3); then 
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b) the normal format variant of DT TPDU numbering (see 6.10). 


The receiving transport entity shall use the following 
procedures; 


c) the normal variant of DT TPDU numbering (see 6.10,; then 


d) reassembling (see 6.3). 


NOTES 
1. The use of RJ TPDU during resynchronization (see 6.14) can 
lead to retransmission. Thus the receipt of a duplicate 
DT TPDU is possible; such a DT TPDU is discarded. 
2. It is possible to decide on a local basis to issue an N- 


RESET request in order to force the remote entity to carry 
out the resynchronization (see 6.14). 


9.2.3.2 Expedited Data 


The transport entities shall use either the network normal data 
or the network expedited variants of the expedited data transfer 
procedure (see 6.11) if their use has been selected during 
connection establishment (see note 1). 


The sending transport entity shall not allocate the same ED- 
TPDU-NR to successive ED TPDUs (see notes 2 and 3). 


When acknowledging an ED TPDU by sending and EA TPDU the 
transport entity shall put into the YR-EDTU-NR parameter of the 
EA TPDU the value received in the ED-TPDU-NR parameter of the ED 
TPDU. 


NOTES 


1. The negotiation of the variant of expedited data transfer 
procedure to be used over the transport connection has 
been designed such that if the initiator proposes the use 
of the network normal data variant (i.e. the mandatory 
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implementation option), the responder has to accept use of 
this option and if the initiator proposes use of the 
network expedited variant, the responder is entitled to 
select use of the network normal data variant. 


2. This numbering enables the receiving transport entity to 
discard repeated ED TPDUs when resynchronization (see 
6.14) has taken place. 


3. No other significance is attached to the ED TPDU-NR 
parameter. It is recommended, but not essential, that the 
values used be consecutive modulo 128. 


9.2.4 Release 


The transport entities shall use the explicit variant of the 
release procedure (see 6.7). 
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10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS 
10.1 Functions of class 2 


Class 2 provides transport connections with or without individual 
flow control; no error detection or error recovery is provided. 


If the network connection resets or disconnects, the transport 
connection is terminated without the transport release procedure 
and the TS-user is informed. 

When explicit flow control is used, a credit mechanism is defined 
allowing the receiver to inform the sender of the exact amount of 


data he is willing to receive and expedited data transfer is 
available. 


10.2 Procedures for class 2 
10.2.1 Procedures applicable at all times 
The transport entities shall use the following procedures 
a) association of TPDUs with transport connection (see 6.9); 
b) TPDU transfer (see 6.2); 
Cc) treatment of protocol errors (see 6.22); 
d) concatenation and separation (see 6.4); 
e) error release (see 6.8). 


Additionally the transport entities may use the following 
procedure: 


f) multiplexing and demultiplexing (see 6.15). 
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10.2.2 Connection establishment 
The transport entities shall use the following procedures: 
a) assignment to network connection (see 6.1); then 


b) connection establishment (see 6.5) and, if applicable 
connection refusal (see 6.6). 


10.2.3 Data transfer when non use of explicit flow control 

has been selected 
If this option has been selected as a result of the connection 
establishment, the transport entities shall use the segmenting 


procedure (see 6.3). 


The TPDU-NR field of DT TPDUs is not significant and may take any 
value. 


NOTE- -Expedited data transfer is not applicable (see 6.5). 


10.2.4 Data transfer when use of explicit flow control 


has been selected 


10.2.4.1 General 
The sending transport entity shall use the following procedures: 
a) segmenting (see 6.3); then 


b) DT TPDU numbering (see 6.10); 
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The receiving transport entity shall use the following 
procedures: 


c) DT TPDU numbering (see 6.10); if a DT TPDU is received 
which is out of sequence it shall be treated as a protocol 
error; then 


d) reassembling (see 6.3). 


The variant of the DT TPDU numbering which is used by both 
transport entities shall be that which was agreed at 
connection establishment. 


10.2.4.2 Flow control 


The transport entities shall send an initial credit (which may be 
zero) in the CDT field of the CR or CC TPDU. This credit 
represents the initial value of the upper window edge allocated 
to the peer entity. 


The transport entity that receives the CR or the CC TPDU shall 
consider its lower window edge as zero, and its upper window edge 
as the value of the CDT field in the received TPDU. 


In order to authorize the transmission of DT TPDUs, by its peer, 
a transport entity may transmit an AK TPDU at any time, subject 
to the following constraints: 


a) the YR-TU-NR parameter shall be at most one greater than 
the TPDU-NR field of the last received DT TPDU or shall be 
zero if no DT TPDU has been received; 


b) if an AK TPDU has previously been sent the value of the 
YR-TU-NR parameter shall not be lower than that in the 
previously sent AK TPDU. 


Cc) the sum of the YR-TU-NR and CDT fields shall not be less 


than the upper window edge allocated to the remote entity 
(see note 1). 
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A transport entity which receives an AK TPDU shall consider the 
YR-TU-NR field as its new lower window edge, and the sum of YR- 
TU-NR and CDT as its new upper window edge. If either of these 
have been reduced or if the lower window edge has become more 
than one greater than the TPDU-NR of the last transmitted DT 
TPDU, this shall be treated as a protocol error (see 6.22). 


A transport entity shall not send a DT TPDU with a TPDU-NR 
outside of the transmit window (see notes 2 and 3). 


NOTES 

1. This means that credit reduction is not applicable. 

2. This means that a transport entity is required to stop 
sending if the TPDU-NR field of the next DT TPDU which 
would be sent would be the upper window edge. Sending of 
DT TPDU may be resumed if an AK TPDU is received which 
increases the upper window edge. 

3. The rate at which a transport entity progresses the upper 


window edge allocated to its peer entity constrains the 
throughput attainable on the transport connection. 


10.2.4.3 Expedited data 


The transport entities shall follow the network normal variant of 
the expedited data transfer procedure in 6.11 if its use has been 
agreed during connection establishment. ED and EA TPDUs 
respectively are not subject to the flow control procedures in 
10.2.4.2. The ED-TPDU-NR and YR-ETDU-NR fields of ED and EA 
TPDUs respectively are not significant and may take any value. 
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10.2.5 Release 


The transport entities shall use the explicit variant of the 
release procedure in 6.7. 
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11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND MULTIPLEXING 
CLASS 


11.1 Functions of Class 3 

Class 3 provides the functionality of Class 2 (with use of 
explicit flow control) plus the ability to recover after a 
failure signalled by the Network Layer without involving the user 


of the transport service. 


The mechanisms used to achieve this functionality also allow the 
implementation of more flexible flow control. 


11.2 Procedures for Class 3 
11.2.1 Procedures applicable at all times 
The transport entities shall use the following procedures: 
a) association of TPDUs with transport connections (see 6.9); 


b) TPDU transfer (see 6.2) and retention until 
acknowledgement of TPDUs (AK variant only) (see 6.13); 


c) treatment of protocol errors (see 6.22); 
d) concatenation and separation (see 6.4); 


e) reassignment after failure (see 6.12), together with 
resynchronization (see 6.14); 


f) frozen references (see 6.18). 


Additionally, the transport entities may use the following 
procedure: 


g) multiplexing and demultiplexing (see 6.15); 
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11.2.2 Connection Establishment 
The transport entities shall use the following procedures; 
a) assignment to network connections (see 6.1); then 


b) connection establishment (see 6.5) and, if appropriate, 
together with connection refusal (see 6.6). 


11.2.3 Data Transfer 

11.2.3.1 General 

The sending transport entity shall use the following procedures: 
a) segmenting (see 6.3), then 


b) DT TPDU numbering (see 6.10); after receipt of an RJ TPDU 
(see 11.2.3.2) the next DT TPDU to be sent may have a 
value which is not the previous value of TPDU-NR plus one. 


The receiving transport entity shall use the following 
procedures: 


c) DT TPDU numbering (see 6.10); the TPDU-NR field of each 
received DT TPDU shall be treated as a protocol error if 
it exceeds the greatest such value received in a previous 
DT TPDU by more than one (see note); then 


d) reassembling (see 6.3); duplicated TPDUs shall be 
eliminated before reassembling is performed. 


NOTE - The use of RJ TPDUs (see 11.2.3.2) can lead to 
retransmission and reduction of credit. Thus the receipt of a DT 
TPDU which is a duplicate, or which is greater than or equal to 
the upper window edge allocated to the peer entity, is possible 
and is therefore not treated as a protocol error. 


91 


11.2.3.2 Use of RJ TPDU 


A transport entity may send an RJ TPDU at any time in order to 
invite retransmission or to reduce the upper window edge 
allocated to the peer entity (see note 1). 


When an RJ TPDU is sent, the following constraints shall be 
respected: 


a) the YR-TU-NR parameter shall be at most one greater than 
the greatest such value received in a previous DT TPDU, or 
shall be zero if no DT TPDU has yet been received (see 
note 2); 


b) if an AK or RJ TPDU has previously been sent the YR-TU-NR 
parameter shall not be lower than that in the previously 
sent AK or RJ TPDU or lower than zero if no AK or RJ TPDU. 


When a transport entity receives an RJ TPDU (see note 3): 
c) the next DT TPDU to be transmitted, or retransmitted, 


shall be that for which the value of the TPDU-NR parameter 
is equal to the value of the YR-TU-NR parameter of the RJ 


TPDU; 

d) the sum of the values of the YR-TU-NR and CDT parameters 
of the RJ TPDU becomes the new upper window edge (see note 
4). 


NOTES 


1. An RJ TPDU can also be sent as part of the 
resynchronization (see 6.14) and reassignment after 
failure (see 6.12) procedures. 


2. It is recommended that the YR-TU-NR parameter be equal to 
the TPDU-NR parameter of the next expected DT TPDU. 


3. These rules are a subset of those specified for when an RJ 


TPDU is received during resynchronization (see 6.14) and 
reassignment after failure (see 6.12). 
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4. This means that RJ TPDU can be used to reduce the upper 
window edge allocated to the peer entity (credit 
reduction). 


11.2.3.3 Flow Control 
The procedures shall be as defined in 10.2.4.2, except that: 


a) a credit reduction may lead to the reception of a DT TPDU 
with a TPDU-NR parameter whose value is not, but would 
have been less than the upper window edge allocated to the 
remote entity prior to the credit reduction. This shall 
not be treated as a protocol error; 


b) receipt of an AK TPDU which sets the lower window edge 
more than one greater than the TPDU-NR of the last 
transmitted DT TPDU shall not be treated as a protocol 
error, provided that all acknowledged DT TPDUs have been 
previously transmitted (see notes 1 and 2). 


NOTES 
1. This can only occur during retransmission following 
receipt of an RJ TPDU. 
2. The transport entity may either continue retransmission as 
before or retransmit only those DT TPDUs, not acknowledged 
by the AK  TPDU. In either case, copies of the 


acknowledged DT TPDUs, need not be retained further. 


11.2.3.4 Expedited data 
The transport entities shall follow the network normal data 
variant of expedited data transfer procedure in 6.11 if its use 


has been agreed during connection establishment. 


The sending transport entity shall not allocate the same ED- 
TPDU-NR to successive ED TPDUs. 
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The receiving transport entity shall transmit an EA TPDU with the 
same value in its YR-EDTU-NR parameter. If, and only if, this 
number is different from that of the previously received ED TPDU 
shall it generate a T-EXPEDITED DATA indication to convey the 
data to the TS-user (see note 2). 


NOTES 
1. No other significance is attached to the ED-TPDU-NR 
parameter. It is recommended, but not essential, that the 
values be consecutive modulo 2**n, where n is the number 


of bits of the parameter. 


2. This procedure ensures that the TS-user does not receive 
data corresponding to the same ED TPDU more than once. 


11.2.4 Release 


The transport entities shall use the explicit variant of the 
release procedure in 6.7. 
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12 SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS 
12.1 Functions of Class 4 


Class 4 provides the functionality of Class 3, plus the ability 
to detect and recover from lost, duplicated, or out of sequence 
TPDUs without involving the TS-user. 


This detection of errors is made by extended use of the DT  TPDU 
numbering of Class 2 and Class 3, by time-out mechanisms, and by 
additional procedures. 


This class additionally detects and recovers from damaged TPDUs 
by using a checksum mechanism. The use of the checksum mechanism 
must be available but its use or its non-use is subject to 
negotiation. 


Further on this class provides additional resilience against 


network failure and increased throughput capability by allowing a 
transport connection to make use of multiple network connections. 


12.2 Procedures for Class 4 
12.2.1 Procedures available at all times 
12.2.1.1 Timers used at all times 


This subclause defines timers that apply at all times in class 4. 
These timers are listed in table 7. 


This International Standard does not define specific values for 
the timers, and the derivations described in this subclause are 
not mandatory. The values should be chosen so that the required 
quality of service can be provided, given the known 
characteristics of the network. 


Timers that apply only to specific procedures are defined under 
the appropriate procedure. 
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+--------------------------- | ------------------------------------ + 
| Symbol | Name | Definition 
eae ic ea R maa 
| MLR |NSDU lifetime | A bound for the maximum time which | 
| | local-to-remote | may elapse between the transmis- | 
| | | sion of an NSDU by a local trans- | 
| port entity and the receipt of any | 
| | | copy of it by a remote peer ias 
| | 
| MRL |NSDU lifetime | A bound for the maximum time which | 
| | remote-to-local | may elapse between the transmission| 
| | | of an SNDU from a remote transport | 
| | | entity to a remote peer entity. | 
| ELR |Expected maximum | A bound for the maximum delay suf- | 
| [transit delay | fered by all but a small proportion| 
| | local-to-remote | of NSDUs transferred from the local| 
| | | transport entity to a remote peer | 
| | | entity. | 
| ERL |Expected maximum | A bound for the maximum delay suf- | 
| [transit delay | fered by all but a small proportion| 
| | remote-to-local | of NSDUs transferred from a remote | 
| | | transport entity to the local peer | 
| | | entity. | 
| AL [Local acknowledge | A bound for the maximum time which | 
| [time | can elapse between the receipt of | 
| | | a TPDU by the local transport en- | 
| | | tity from the network layer and | 
| the transmission of the corres- | 
| | | ponding acknowledgement. 
| | 
| AR [Remote acknow- | As AL, but for the remote entity. | 
| | ledgement time | | 
tae SS SRS A R R E E E AE Sees + 
Table 7. (First of 2 pages) Time Parameters related to class 4 
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T1 |Local retrans- 
[mission time 


Persistence time 


Maximum number of 


[transmissions 


Bound on references 
and sequence 


| 
| 
| 
| 
| 
| 
| 
| 
| numbers | 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Inactivity time 


Window time 


A bound for the maximum time that 
the local transport entity will 
wait for acknowledgement before re- 
transmitting a TPDU. 


A bound for the maximum time the 
the local transport entity will 

continue to transmit a TPDU that 
requires acknowledgement. 


A bound for the maximum number of 
times which the local transport 
entity will continue to transmit a 
TPDU that requires acknowledgement. 


A bound for the maximum time 
between the transmission of a TPDU 
and the receipt of any acknow- 
ledgement relating to it. 


A bound for the time after which 

a transport entity will, if it 
does not receive a TPDU, initiate 
the release procedure to terminate 
the transport connection. 


NOTE - This parameter is required 
for protection against unsignalled 
breaks in the network connection. 


A bound for the maximum time a 
transport entity will wait before 
retransmitting up to date window 
information. 


Table 7. 


(Second of 2 pages) 


Time Parameters related to class 4 
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12.2.1.1.1 NSDU lifetime (MLR, MRL) 


The network layer is assumed to provide, as an aspect of its 
grade of service, for a bound on the maximum lifetime of NSDUs in 
the network. This value may be different in each direction of 


transfer through a network between two transport entities. The 
values, for both directions of transfer, are assumed to be Known 
by the transport entities. The maximum NSDU lifetime local-to- 


remote (MLR) is the maximum time which may elapse between the 
transmission of an NSDU from the local transport entity to the 
network and receipt of any copy of the NSDU from the network at 
the remote transport entity. The maximum NSDU lifetime remote- 
to-local (MRL) is the maximum time which may elapse between the 
transmission of an NSDU from the remote transport entity to the 
network and receipt of any copy of the NSDU from the network at 
the local transport entity. 


12.2.1.1.2 Expected maximum transit delay (ELR, ERL) 


The network layer is assumed to provide, as an aspect of its 
grade of service, an expected maximum transit delay for NSDUs in 
the network. This value may be different in each direction of 


transfer through a network between two transport entities. The 
values, for both directions of transfer, are assumed to be Known 
by the transport entities. The expected maximum transit delay 


local-to-remote (ELR) is the maximum delay suffered by all but a 
small proportion of NSDUs transferred through the network from 
the local transport entity to the remote transport entity. The 
expected maximum transit delay remote-to-local (ERL) is the 
maximum delay suffered by all but a small proportion of NSDUs 
transfer through the network from the remove transport entity to 
the local transport entity. 
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12.2.1.1.3 Acknowledge Time (AR, AL) 


Any transport entity is assumed to provide a bound for the 
maximum time which can elapse between its receipt of a TPDU from 
the Network Layer and its transmission of the corresponding 
response. This value is referred to as AL. The corresponding 
time given by the remote transport entity is referred to as AR. 


12.2.1.1.4 Local retransmission time (T1) 
The local transport entity is assumed to maintain a bound on the 
time it will wait for an acknowledgement before retransmitting 


the TPDU. Its value is given by: 


Tl = ELR + ERL + AR + X 


where: 
ELR = Expected maximum transit delay local-to-remote, 
ERL = Expected maximum transit delay remote-to-local, 
AR = Remote acknowledge time, and 
X = local processing time for a TPDU. 


12.2.1.1.5 Persistence Time (R) 


The local transport entity is assumed to provide a bound for the 
maximum time for which it may continue to retransmit a TPDU 
requiring positive acknowledgement. This value is referred to as 
R. 


The value is clearly related to the time elapsed between 
retransmission, Tl, and the maximum number of transmissions, N. 
It is not less than Tl * N + X, where X is a small quantity to 
allow for additional internal delays, the granularity of the 
mechanism used to implement T1 and so on. Because R is a bound, 
the exact value of X is unimportant as long as it is bounded and 
the value of a bound is known. 
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12.2.1.1.6 Bound on References and Sequence Numbers (L) 

A bound for the maximum time between the decision to transmit a 
TPDU and the receipt of any response relating to it (L) is given 
by: 


L = MLR + MRL + R + AR 


where: 
MLR = NSDU lifetime local-to-remote, 
MRL = NSDU lifetime remote-to-local, 
R = Persistence time, and 
AR = Remote acknowledgement time. 


It is necessary to wait for a period L before reusing any 
reference of sequence number, to avoid confusion in case a TPDU 
referring to it may be duplicated or delayed. 


NOTES 
1. In practice, the value of L may be unacceptably large. It 
may also be only a statistical figure at a certain 
confidence level. A smaller value may therefore be used 
where this still allows the required quality of service to 
be provided. 
2. The relationships between times discussed above are 


illustrated in figures 3 and 4. 


[Figures 3 and 4 are omitted from this copy.] 


12.2.1.2 General Procedures 
The transport entity shall use the following procedures: 
a) TPDU transfer (see 6.2); 


b) association of TPDUs with transport connections (see 6.9); 
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Cc) treatment of protocol errors (see 6.22); 

d) checksum (see 6.17); 

e) splitting and recombining (see 6.23); 

f) multiplexing and demultiplexing (see 6.15); 

g) retention until acknowledgement of TPDUs (see 6.13); 

h) frozen references (see 6.18). 

j) retransmission procedures; when a transport entity has 

some outstanding TPDUs that require acknowledgement, it 
will check that no Tl interval elapses without the arrival 
of a TPDU that acknowledges at least one of the 
outstanding TPDUs. 
If the timer expires, except if the TPDU to be 
retransmitted is a DT TPDU and it is outside the transmit 
window due credit reduction, the first TPDU is 
retransmitted and the timer is restarted. After N 
transmissions (i.e. N-1 retransmissions) it is assumed 
that useful two-way communication is no longer possible 
and the release procedure is used, and the TS-user is 
informed. 

NOTES 

1) This procedure may be implemented by different means. For 
example: 

a) one interval is associated with each  TPDU. If the 


timer expires the associated TPDU will be transmitted 
and the timer T1 will be restarted for all subsequent 
TPDUs; or 


b) one interval is associated with each transport 
connection: 


1) if the transport entity transmits a TPDU requiring 
acknowledgement, it starts timer T1; 
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12.2.2 


i AA 2 


2) if the transport entity receives a TPDU that 
acknowledges one of the TPDUs to be acknowledged, 
it restarts timer Tl unless the received TPDU is 
an AK which explicitly closes the transmit window. 


3) if the transport entity receives a TPDU that 
acknowledges the last TPDU to be acknowledged, it 
stops timer T1. 


For a decision whether the retransmission timer Tl is 
maintained on a per TPDU or on a per transport connection 
basis, throughput considerations have to be taken into 
account. 


For DT TPDUs it is a local choice to retransmit either 
only the first DT TPDU or all TPDUs waiting for an 
acknowledgement up to the upper window edge. 


It is recommended that after N transmissions of a DT TPDU, 
the transport entity waits T1 + W + MRL to provide a 
higher possibility of receiving an acknowledgement before 
entering the release phase. For other TPDU types which 
may be retransmitted, it is recommended that after N 
transmissions the transport entity waits T1 + MRL to 
provide a higher possibility of receiving the expected 
reply. 


Procedures for Connection Establishment 


1 Timers used in Connection Establishment 


There are no timers specific to connection establishment. 
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1222.2 


General Procedures 


The transport entities shall use the following procedures: 


a) 


b) 


assignment to network connection (see 6.1); 


connection establishment (see 6.5) and if appropriate 
connection refusal (see 6.6) together with the additional 
procedures: 

1) a connection is not considered established until the 


successful completion of a 3-way TPDU exchange. The 
sender of a CR TPDU shall respond to the corresponding 
CC TPDU by immediately sending a DT, ED, DR or AK 
TPDU; 


as a result of duplication or retransmission, a CR 
TPDU may be received specifying a source reference 
which is already in use with the sending transport 
entity. If the receiving transport entity is in the 
data transfer phase, having completed the 3-way TPDU 
exchange procedure, or is waiting for the T-CONNECT 
response from the TS-user, the receiving transport 
entity shall ignore such a TPDU. Otherwise a CC TPDU 
shall be transmitted; 


as a result of duplication or retransmission, a CC 
TPDU may be received specifying a paired reference 
which is already in use. The receiving transport 
entity shall only acknowledge the duplicate CC TPDU 
according to the procedure in 12.2.2.2.b.1. 


a CC TPDU may be received specifying a reference which 
is in the frozen state. The response to such a TPDU 
shall be a DR TPDU; 


the retransmission procedures (see 12.2.1.2) are used 
for both the CR TPDU and CC TPDU. 
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12.2.3 Procedures for Data Transfer 
12.2.3.1 Timers used in Data Transfer 
The data transfer procedures use two additional timers: 
a) Inactivity Time (I) 
To protect against unsignalled breaks in the network 
connection or failure of the peer transport entity (half-open 
connections), each transport entity maintains an inactivity 
interval. The interval must be greater than E. 
NOTE - A suitable value for I is given by 
2 * (N * maximum of (T1, W)) 
unless local needs indicate another more appropriate value. 
b) Window Time (W) 
A transport entity maintains a timer interval to ensure that 


there is a bound on the maximum interval between window 
updates. 


12.2.3.2 General Procedures for data transfer 

The transport entities shall use the following procedures: 
a) inactivity control (see 6.21); 
b) expedited data (see 6.11); 
c) explicit flow control (see 6.16). 


The sending transport entity shall use the following procedures 
in the following order: 


d) segmenting (see 6.3); 


e) DT TPDU numbering (see 6.10). 
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The receiving transport entity shall use the following procedures 
in the following order: 


f) DT TPDU numbering (see 6.10); 
g) resequencing (see 6.20); 
h) reassembling (see 6.3). 


12.2.3.3 Inactivity Control 


If the interval of the inactivity timer I expires without receipt 
of some TPDU, the transport entity shall initiate the release 
procedures. To prevent expiration of the remote transport 
entity’s inactivity timer when no data is being sent, the local 
transport entity must send AK TPDUs at suitable intervals in the 
absence of data, having regard to the probability of TPDU loss. 
The window synchronization procedures (see 12.2.3.8) ensure that 
this requirement is met. 


NOTE - It is likely that the release procedure initiated due to 
the expiration of the inactivity timer will fail, as such 
expiration indicates probable failure of the supporting network 
connection or of the remote transport entity. 


12.2.3.4 Expedited Data 


The transport entities shall follow the network normal data 
variant of the expedited data transfer procedures (see 6.11), if 
the use of transport expedited service option has been agreed 
during connection establishment. 


The ED TPDU shall have a TPDU-NR which is allocated from a 
separate sequence space from that of the DT TPDUs. 


A transport entity shall allocate the sequence number zero to the 
ED TPDU-NR of the first ED TPDU which it transmits for a 
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transport connection. For subsequent ED TPDU sent on the same 
transport connection, the transport entity shall allocate a 
sequence number one greater than the previous one. 


Modulo 2**7 arithmetic shall be used when normal formats have 
been selected and modulo 2**31 arithmetic shall be used when 
extended formats have been selected. 


The receiving transport entity shall transmit an EA TPDU with the 
same sequence number in its YR-ETDU-NR field. If this number is 
one greater than in the previously in sequence received ED TPDU, 
the receiving transport entity shall transfer the data in the ED 
TPDU to the TS-user. 


If a transport entity does not receive an EA TPDU in 
acknowledgement to an ED TPDU it shall follow the retransmission 
procedures (see note and 12.2.1.2). 


The sender of an ED TPDU shall not send any new DT TPDU with 
higher TPDU-NR until it receives the EA TPDU. 


NOTE - This procedure ensures that ED TPDUs are delivered to the 
TS-user in sequence and that the TS-user does not receive data 
corresponding to the same ED TPDU more than once. Also it 
guarantees the arrival of the ED TPDU before any subsequently 
sent DT TPDU. 


12.2.3.5 Resequencing 


The receiving transport entity shall deliver all DT TPDUs to the 
TS-user in the order specified by the sequence number field. 


DT TPDUs received out-of-sequence but within the transmit window 
shall not be delivered to the TS-user until all in-sequence TPDUs 
have been received. DT TPDU received out-of-sequence and outside 
the transmit window shall be discarded. 


Duplicate TPDUs can be detected because the sequence number 
matches that of preciously received TPDUs. Sequence numbers 
shall not be reused for the period L after their previous use. 
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Otherwise, a new, valid TPDU could be confused with a duplicated 
TPDU which had previously been received and acknowledged. 


Duplicated DT TPDUs shall be acknowledged, since the duplicated 
TPDU may be the result of a retransmission resulting from the 
loss of an AK TPDU. 


The data contained in a duplicated DT TPDU shall be ignored. 


12.2.3.6 Explicit Flow Control 


The transport entities shall send an initial credit (which may 
take the value 0) in the CDT field of the CR TPDU or CC TPDU. 
This credit represents the initial value of the upper window edge 
of the peer entity. 


The transport entity which receives the CR TPDU or CC TPDU shall 
consider its lower window edge as zero and its upper window edge 
as the value in the CDT field in the received TPDU. 


In order to authorize the transmission of DT TPDUs by its peer, a 
transport entity may transmit an AK TPDU at any time. 


The sequence number of an AK TPDU shall not exceed the sequence 
number of the next expected DT TPDU, i.e. it shall not be greater 
than the highest sequence number of a received DT TPDU, plus one. 


A transport entity may send a duplicate AK TPDU containing the 
same sequence number, CDT, and subsequence number field at any 
time. 


A transport entity which receives an AK TPDU shall consider the 
value of the YR-TU-NR field as its new lower window edge if it is 
greater than any previously received in a YR-TU-NR field, and the 
sum of YR-TU-NR and CDT as its new upper window edge subject to 
the procedures for sequencing AK TPDUs (see 12.2.3.8). A 
transport entity shall not transmit or retransmit a DT TPDU with 
a sequence number outside the transmit window. 
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12.2.3.7 Sequencing of received AK TPDUs 


To allow a receiving transport entity to properly sequence a 
series of AK TPDUs that all contain the same sequence number and 
thereby use the correct CDT value, AK TPDUS may contain a 
subsequence parameter. For the purpose of determining the 
correct sequence of AK TPDUs, the absence of the subsequence 
parameter shall be equivalent to the value of the parameter set 
to zero. 


An AK TPDU is defined to be in sequence if: 


a) the sequence number is greater than in any previously 
received AK TPDU, or 


b) the sequence number is equal to the highest in any 
previously received AK TPDU, and the subsequence parameter 
is greater than in any previously received AK TPDU having 
the same value for YR-TU-NR field, or 


c) the sequence number and subsequence parameter are both 
equal to the highest in any previously received AK TPDU 
and the credit field is greater than or equal to that in 
any previously received AK TPDU having the same YR-TU-NR 
field. 


A transport entity is not required to include the subsequence 


number in its AK TPDUs. It may also choose not to use the 
subsequence parameter in sequencing received AK TPDUs. If a 
transport entity chooses not to recognize the subsequence 


parameter it shall still sequence received AK TPDUs according to 
V2 258i. Tiaa 


When the receiving transport entity recognizes an out of sequence 
AK TPDU it shall ignore it. 
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12.2.3.8 Procedure for transmission of AK TPDUs 
12.2.3.8.1 Retransmission of AK TPDUs for window synchronization 


A transport entity shall not allow an interval W to pass without 
the transmission of an AK TPDU. if the transport entity is not 
using the procedure following setting CDT to zero (see 
12.2.3.8.3) or reduction of the upper window edge (see 
12.2.3.8.4), and does not have to acknowledge receipt of any DT 
TPDU, then it shall achieve this by retransmission of the most 
recent AK TPDU, with up-to-date window information. 


NOTE - The use of the procedures defined in 12.2.3.8.3 and 
12.2.3.8.4 are optional for any transport entity. The protocol 
operates correctly either with or without these procedures which 
are defined to enhance the efficiency of its operation. However, 
if these procedures are not used then W must be set to ensure 
enough retransmissions of the AK TPDU so that release of TC is 
avoided. The value of W should be approximately 
W = (T1 * N)/(N-1) when the procedures are not used. 


12.2.3.8.2 Sequence control for transmission of AK TPDUs 


To allow the receiving transport entity to process AK TPDUs in 
the correct sequence, as described in 12.2.3.7, the subsequence 
parameter may be included following reduction of CDT. If the 
value of the subsequence number to be transmitted is zero, then 
the parameter should be omitted. 


The value of the subsequence parameter, if used, shall be zero 
(either explicitly or by absence of the parameter) if the 
sequence number is greater than the field in previous AK TPDUs, 
sent by the transport entity. 


If the sequence number is the same as the previous AK TPDU sent 
and the CDT field is equal to or greater than the CDT field in 
the previous AK TPDU sent then the subsequence parameter, if 
used, shall be equal to that in the previously sent AK TPDU. 


If the sequence number is the same as the previous AK TPDU sent 
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and the CDT field is less than the value of the CDT field in the 
previous AK TPDU sent than the subsequence parameter, if used, 
shall be one greater than the value in the previous AK TPDU.. 


12.2.3.8.3 Retransmission of AK TPDUs after CDT set to zero 


Due to the possibility of loss of AK TPDUs, the upper window edge 
as perceived by the transport entity transmitting an AK TPDU may 
differ from that perceived by the intended recipient. To avoid 
the possibility of extra delay, the retransmission procedure (see 
12.2.1.2) should be followed for an AK TPDU, if it opens the 
transmit window which has previously been closed by sending an AK 
TPDU with CDT field set to zero. 


The retransmission procedure, if used, terminates and the 
procedure in 12.2.3.8.1 is used when: 


a) an AK TPDU is received containing the flow control 
confirmation parameter, whose lower window edge and your 
subsequence fields are equal to the sequence number and 
subsequence number in the retained AK TPDU and whose 
credit field is not zero. 


b) an AK TPDU is transmitted with a sequence number higher 
than that in the retained AK TPDU, due to reception of a 
DT TPDU whose sequence number is equal to the lower window 
edge; 


c) N transmissions of the retained AK TPDU have taken place. 
In this case the transport entity shall continue to 
transmit the AK TPDU at an interval of W. 


An AK TPDU which is subject to the retransmission procedure shall 
not contain the flow control confirmation parameter. If it is 
required to transmit this parameter concurrently, an additional 
AK TPDU shall be transmitted having the same values in the 
sequence, subsequence (if applicable) and credit fields. 


110 


12.2.3.8.4 Retransmission procedures following reduction of the 
upper window edge 


This subclause specifies the procedure for retransmission of AK 
TPDUs after a transport entity has reduced the upper window edge 
(see 12.2.3.6) or for an AK TPDU with the credit field set to 
zero. This procedure is used until the lower window edge exceeds 
the highest value of the upper window edge ever transmitted (i.e. 
the value existing at the time of credit reduction, unless a 
higher value is retained from a previous credit reduction). 


This retransmission procedure should be followed for any AK TPDU 
which increases the upper window edge, unless an AK TPDU has been 
received containing a flow control confirmation parameter, which 
corresponds to an AK TPDU transmitted following credit reduction, 
for which the sum of the credit and lower window edge fields 
(i.e. the upper window edge value) is greater than the lower 
window edge (YR-TU-NR field) of the transmitted AK TPDU. 


This retransmission procedure for any particular AK TPDU shall 
terminate when: 


a) an AK TPDU is received containing the flow control 
confirmation parameter, whose lower window edge and your 
subsequence fields are equal to the lower window edge and 
subsequence number in the retained AK TPDU; or 


b) N transmissions of the retained AK TPDU have taken place. 
In this case the transport entity shall continue to 
transmit the AK TPDU at an interval of W. 


An AK TPDU which is subject to the retransmission procedure shall 
not contain the flow control confirmation parameter. If it is 
required to transmit this parameter concurrently, an additional 
AK TPDU shall be transmitted having the same values in the 
sequence, subsequence (if applicable) and credit fields. 


NOTE - Retransmission of AK TPDUs is normally not necessary, 
except following explicit closing of the window (i.e. 
transmission of an AK TPDU with CDT field set to zero). If 
data is available to be transmitted, the retransmission 
procedure for DT TPDUs will ensure that an AK TPDU is received 
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granting further credit where this is available. Following 
credit reduction, this may no longer be so, because 
retransmission may be inhibited by the credit reduction. The 
rules described in this clause avoid extra delay. 


The rules for determining whether to apply the retransmission 
procedure to an AK TPDU may be expressed alternatively as 
follows. Let: 


LWE = lower window edge 

UWE upper window edge 

KUWE lower bound on upper window edge 
held by remote transport entity 


The retransmission procedure is to be used whenever: 
(UWE>LWE) and (KUWE = LWE) 


i.e. when the window is opened and it is not known definitely 
that the remote transport entity is aware of this. 


KUWE is maintained as follows. When credit is reduced, KUWE is 
set to LWE. Subsequently, it is increased only upon receipt of a 
valid flow control confirmation (i.e. one which matches the 
retained lower window edge and subsequence). In this case KUWE 
is set to the implied upper window edge of the flow control 
confirmation, i.e. the sum of its lower window edge and your 
credit fields. By this means, it can be ensured that KUWE is 
always less than or equal to the actual upper window edge in use 
by the transmitter of DT TPDUs. 


12.2.3.9 Use of Flow Control Confirmation parameter 


At any time, an AK TPDU may be transmitted containing a flow 
control confirmation parameter. The lower window edge, your 
subsequence and your credit fields shall be set to the same 
values as the corresponding fields in the most recently received 
in sequence AK TPDU. 
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An AK TPDU containing a flow control confirmation parameter 
should be transmitted whenever: 


a) 


12.2.4 


a duplicate AK TPDU is received, with the value of YR-TU- 
NR, CDT, and subsequence fields equal to the most recently 
received AK TPDU, but not itself containing the flow 
control confirmation parameter; 


an AK TPDU is received which increases the upper window 
edge but not the lower window edge, and the upper window 
edge was formerly equal to the lower window edge; or 


an AK TPDU is received which increases the upper window 
edge but not the lower window edge, and the lower window 
edge is lower than the highest value of the upper window 
edge received and subsequently reduced (i.e. following 
credit reduction). 


Procedures for Release 


12.2.4.1 Timers used for Release 


There are no timers used only for release. 


12.2.4.2 General Procedures for Release 


The transport entity shall use the explicit variant of normal 


release 


(see 6.7). 
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13 STRUCTURE AND ENCODING OF TPDUs 


13.1 Validity 


Table 8 specifies those TPDUs which are valid for each class and 


the code for each TPDU. 


KEY: xxxx (bits 4-1): used to signal the CDT 
in classes 0 and 1) 


(set to 0000 


zzzz (bits 4-1): used to signal CDT in classes 2, 3, 


4 set to 1111 in class 


NF: Not available when the 


1 


non explicit 


flow control option is selected. 
NRC: Not available when the receipt 
confirmation option is selected. 
NOTE - These codes are already in use in related protocols 


defined by standards oganizations other than CCITT/ISO. 


114 


HO + 


KMX T E T OTTO TO T OO T AO L VO TOO T o lx l 
|1x1Xx/10/|l/01l1010l1lNl1OoO InNnt_orlrlotreotx lx l 

Ime tM 1TL_orlotrotl!lotnto InIor;r~lotrotx lx l 

3 a MI ek o RI keane a eal era S T 
[e) 1LOI1A4A1010o01A1A410l10 LA4A1A101A1>A4310l1 
O leat orwolrlotrn ll! olxwdia lOi ltl otlnwtiotltxti 
lea toa |! otlnAtinA It! oOotlrlntioao le to IT oroorolrotl 

lata lina ta tin 1001010 hrororoolrotxanta | 

(0) | | | l l | l | | | | | | | | 

n l l l l | | | | oO Io tun i | | l l 

os raya iwnr nt wowlnmiliotroatrx«a lato | | | | 

oO O l . l A] . l sol an] =] ed . l | a A A o tals «sx. 
Nd 1010101010101m010m IMIM I | | | | 

O kat K ua | IEE c aD EE aa A l | | l | 

l l | | l l l l l l l l l l ! 

| | l l | | | l Í | | | | | | l 

I% I XIXI xX Ix I xX ITOK IK I X | I x I | l l | 

| l l l l | l l l l l l l l l | 

[e L= E ————————————————————_—————_————= == 
-d | | | | | | | | | | | | l l | | 
te Io I XIXIXIXIXIXIXI X I XIXI l l l | 
Y | | l l l l l l l | l l l | l l 
AQ A — a | 
z 01 l | l | l IT | & | & | | | | | l l 
nIN IT XI MI MIM IXIA IAI Se l I X I l | l l 
man I | l l l l l l l l l l l l | | 
QOL eh ee aaa 
Ano | | | | l | l =D: Ah | | | | | | | 
DOUI IiXIXIXIXIXIXIØQIX I XIXI | l | l 
-A l l l l | l l IZI l l l l l l | 
qo | — I  - -——_ —__— —____—_——_—_na—__a—____ —__—_— == — | 
© | | | | | | l | | l l | | | | | 
> IO IXIXIXI I X I l l | I X I | | | l 
l l l l l l l l | l l l l l l i 

| | | | l l | pil | | | | 

l l l l l l I G I | | | l 

hab, E E l | ol | l | l 
[1n19101!1$91 l | = l | l | 

| Ol vA tl Ot vA A | | ol | l l | 

rot wHwtl BIH tl l IOI l | l | 
LEMA | 6101 ® | l | | 

| ot!otaotot Ipl olvwy | | | | 

(AE Dee Pd | @ lol @yp | l l l 

l l | | | LAIA | | l 

ER I R- T-I | 1 oO | oO | I H l oO l 

| ADE t E O 1 O POE E > | k Onl ms es E = E | © | qo | 

lA tl At Ot oO | olny! oot I H l Qaa | 

heen © A Al 19p9101pPpol I H l © v l 
10101E81El1 lA} Gl AO 1 Pp! = R H p | 

| ot!oteotot LO | IOO ll | H O | 

1 ataqtotrotlwtovdviti@wtoodvnAtoitpt OG l 

FR a u TE ntiniypt O BE Qaeini atl > | 

| ol Oa od to | @1lxRN tt o@otlxw ototaA | © oO l 

LORU A AnA A A ed (0) | 

| | | | | | | l a] | | pn | 

6 bot lm PO. Bb A se 0.1101 Q- | 

IO IOIAIAIAIĦMÐMIKSIHAK IMIM I S | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


TPDU code 


Table 8. 


LIS 


13.2 Structure 


All the transport protocol data units (TPDUs) shall contain an 
integral number of octets. The octets in a TPDU are numbered 
starting from 1 and increasing in the order they are put into an 
NSDU. The bits in an octet are numbered from 1 to 8, where bit 1 
is the low-ordered bit. 


When consecutive octets are used to represent a binary number, 
the lower octet number has the least significant value. 


NOTE - When the encoding of a TPDU is represented using a 
diagram in this clause, the following representation is used: 


a) octets are shown with the lowest numbered octet to the 
left, higher numbered octets being further to the right; 


b) within an octet, bits are shown with bit 8 to the left and 
bit 1 to the right. 


TPDUs shall contain, in the following order: 
a) the header, comprising: 
1) the length indicator (LI) field; 
2) the fixed part; 
3) the variable part, if present; 
b) the data field, if present. 


This structure is illustrated below: 


octet ab Den 3) Oe ads A TU DS ere p ptl ...end 
+---4------------- Ho => +----------- + 
| LI| fixed part | variable part| data field| 
+---+-----------—- Ho ooo +--------—-- + 
A E E header ------ > 
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13.2.1 Length indicator field 


This field is contained in the first octet of the TPDUs. The 
length is indicated by a binary number, with a maximum value of 
254 (1111 1110). The length indicated shall be the header length 
in octets including parameters, but excluding the length 
indicator field and user data, if any. The value 255 (1111 1111) 
is reserved for possible extensions. If the length indicated 
exceeds the size of the NS-user data which is present, this is a 
protocol error. 


13.2.2 Fixed part 
13.2.2.1 General 


The fixed part contains frequently occurring parameters including 
the code of the TPDU. The length and the structure of the fixed 
part are defined by the TPDU code and in certain cases by the 
protocol class andthe formats in use (normal or extended). If 
any of the parameters of the fixed part have an invalid value, or 
if the fixed part cannot be contained with the header (as defined 
by LI) this is a protocol error. 


NOTE - In general, the TPDU code defines the fixed part 
unambiguously. However, different variants may exist for the 
same TPDU code (see normal and extended formats). 


13.2.2.2 TPDU code 


This field contains the TPDU code and is contained in octet 2 of 
the header. It is used to define the structure of the remaining 
header. This field is a full octet except in the following 
cases: 
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1110 xxxx Connection Request 


1101 xxxx Connection Confirm 
0101 xxxx Reject 
0110 xxxx Data Acknowledgement 


where xxxx (bits 4-1) is used to signal the CDT. 


Only those codes defined in 13.1 are valid. 


13.2.3 Variable part 


The variable part is used to define less frequently used 
parameters. If the variable part is present, it shall contain 
one or more parameters. 


NOTE - The number of parameters that may be contained in the 
variable part is indicated by the length of the variable part 
which is LI minus the length of the fixed part. 


Each parameter contained within the variable part is structured 
as follows: 


Bits 8 7 6 5 4 3 2 1 
Octets Bhi te E a Se ee Fee Tee + 
n+1 | Parameter Code | 
n+2 Parameter Length 


| Indication (e.g. m) | 
n+3 | | 


n+2+m | | 
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- The parameter code field is coded in binary; 


NOTE - Without extensions, it provides a maximum number of 255 


different parameters. However, as noted below, bits 8 and 7 
cannot take every possible value, so the practical maximum 
number of different parameters is less. Parameter code 1111 


1111 is reserved for possible extensions of the parameter code. 


- The parameter length indication indicates the length, in 
octets, of the parameter value field. 


NOTE - The length is indicated by a binary number, m, with a 
theoretical maximum value of 255. The practical maximum value 
of m is lower. For example, in the case of a single parameter 
contained within the variable part, two octets are required for 
the parameter code and the parameter length indication itself. 
Thus, the value of m is limited to 248. For larger fixed parts 
of the header and for each succeeding parameter, the maximum 
value of m decreases. 


- The parameter value field contains the value of the parameter 
identified in the parameter code field. 


- No parameter codes use bits 8 and 7 with the value 00. 


- The parameters defined in the variable part may be in any 
order. If any parameter is duplicated then the later value 
shall be used. A parameter not defined in this International 
Standard shall be treated as a protocol error in any received 
TPDU except a CR TPDU; in a CR TPDU it shall be ignored. If 
the responding transport entity selects a class for which a 
parameter of the CR TPDU is not defined, it may ignore this 
parameter, except the class and option, and alternative 
protocol class parameters which shall always be interpreted. A 
parameter defined in this International Standard but having an 
invalid value shall be treated as a protocol error in any 
received TPDU except a CR _  TPDU. In a CR TPDU it shall be 
treated as a protocol error if it is either the class and 
option parameter or the alternative class parameter or the 
additional option parameter; otherwise it shall be either 
ignored or treated as a protocol error. 
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13.2.3.1 Checksum Parameter (Class 4 only) 


All TPDU types may contain a 16-bit checksum parameter in their 
variable part. This parameter shall be present in a CR TPDU and 
shall be present in all other TPDUs except when the non use of 
checksum option is selected. 


Parameter Code: 1100 0011 
Parameter Length: 2 
Parameter Value: Result of checksum algorithm. This algorithm 


is specified in 6.17. 


13.2.4 Data Field 


This field contains transparent user data. Restrictions on its 
size are noted for each TPDU. 


13.3 Connection Request (CR) TPDU 


The length of the CR TPDU shall not exceed 128 octets. 


13.3.1 Structure 


The structure of the CR TPDU shall be as follows: 


i 2 3 4 5 6 7 8 p p+l...end 
+--+------ 4+--------- 4+--------- 4+---+---+------ 4+------- 4+--------- + 
|LI|CR CDT] DST - REF |SRC-REF|CLASS |VARIAB. | USER | 
| |1110 |0000 0000|0000 0000| | |OPTION|PART [DATA | 
+--+------ 4+--------- 4+--------- 4+---+---+------ 4+------- 4+--------- + 


120 


13.3.2 LI 


See 13.2.1 


13.3.3 Fixed Part (Octets 2 to 7) 


The structure of this part shall contain: 


a) CR : Connection Request Code: 1110. Bits 8-5 of 
octet 2; 

b) CDT : Initial Credit Allocation (set to 0000 in 
Classes 0 and 1 when specified as preferred 
class). Bits 4-1 of octet 2; 

Cc) DST-REF : Set to zero; 

d) SRC-REF : Reference selected by the transport entity 


initiating the CR TPDU to identify the 
requested transport connection; 


e) CLASS and Bits 8-5 of octet 7 defines the preferred 
OPTION: transport protocol class to be operated over 
the requested transport connection. This 
field shall take one of the following values: 


0000 Class 
0001 Class 
0010 Class 
0011 Class 
0100 Class 


SS UYNRO 


The CR TPDU contains the first choice of class in the fixed part. 
Second and subsequent choices are listed in the variable part if 
required. 


Bits 4-1 of octet 7 define options to be used on the requested 
transport connection as follows: 


EZ 


4===-- | ----------------------------------------------- + 

| BIT | OPTION | 

| 4 | 0 always | 

anes San ©) always | 

| 2 | =0 use of normal formats in all classes | 

| | =1 use of extended formats in Classes 2,3,4 | 

| 1 | =0 use of explicit flow control in Class 2 | 

| | =1 no use of explicit flow control in | 

| | Class 2 

FO O O O + 

NOTES 

1. The connection establishment procedure (see 6.5) does not 
permit a given CR TPDU to request use of transport expedited 
data transfer service (additional option parameter) and no 
use of explicit flow control in Class 2 (bit 1 = 1). 

2. Bits 4 to 1 are always zero in Class 0 and have no meaning. 


13.3.4 Variable Part (Octets 8 to p) 
The following parameters are permitted in the variable part: 
a) Transport Service Access Point Identifier (TSAP-ID) 


Parameter code: 1100 0001 for the identifier of the 
Calling TSAP. 
1100 0010 for the identifier of the 
Called TSAP 

Parameter length: not defined in this standard 

Parameter value: identifier of the calling or called 
TSAP respectively. 
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If a TSAP-ID is given in the request it may be returned in 
the confirmation. 


TPDU size 


This parameter defines the proposed maximum TPDU size (in 
octets including the header) to be used over the requested 
transport connection. The coding of this parameter is: 


Parameter code: 1100 0000 
Parameter Length: 1 octet 


Parameter value: 


0000 1101 8192 octets (not allowed in Class 0) 
0000 1100 4096 octets (not allowed in Class 0) 
0000 1011 2048 octets 
0000 1010 1024 octets 
0000 1001 512 octets 
0000 1000 256 octets 
0000 0111 128 octets 


Default value is 0000 0111 (128 octets) 


Version Number (not used if Class 0 is the preferred 
class) 


Parameter code: 1100 0100 

Parameter length: 1 octet 

Parameter value field: 0000 0001 

Default value is 0000 0001 (not used in Class 0) 


Security Parameters (not used if Class 0 is the preferred 
class) 


This parameter is user defined. 


Parameter code: 1100 0101 
Parameter length: user defined 
Parameter value: user defined 


Checksum (used only if class 4 is the preferred class) 
(see 13.2.3.1) 
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This parameter shall always be present in a CR TPDU 
requesting Class 4, even if the checksum selection 
parameter is used to request non-use of the checksum 
facility. 


Additional Option Selection (not used if Class 0 is the 
preferred class) 


This parameter defines the selection to be made as to 
whether or not additional options are to be used. 


Parameter code: 1100 0110 
Parameter length: 1 
Parameter value: 


1= Use of network expedited in Class 1 
O= Non use of network expedited in Class 1 


1= Use of receipt confirmation in Class 1 
0= Use of explicit AK variant in Class 1 


in Class 4 
1= 16-bit checksum defined in 6.17 is not to be 


| | 
| | 
| | 
| | 
| | 
| | 
2 | 0= 16-bit checksum defined in 6.17 is to be used| 
| | 
| | 
| used on Class 4 | 

| | 

| | 

| | 

| | 


A 1= Use of transport expedited data transfer 
service 
0= No use of transport expedited data transfer 
service 
$ -- - - - - = = + 


Default value is 000 0001 
Bits related to options particular to a class are not 


meaningful if that class is not proposed and may take any 
value. 
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Alternative protocol class(es) (not used if Class 0 is the 
preferred class) 


Parameter code: 1100 0111 
Parameter length: n 


Parameter value encoded as a sequence of single octets. 
Each octet is encoded as for octet 7 but with bits 4-1 set 
to zero (i.e. no alternative option selections permitted). 


Acknowledge Time (used only if class 4 is the preferred 
class) 


This parameter conveys the maximum acknowledge time AL to 
the remote transport entity. It is an indication only, 
and is not subject to negotiation (see 12.2.1.1.3) 
Parameter code: 1000 0101 
Parameter length: 2 
Parameter value: n, a binary number where n is the 
maximum acknowledge time, expressed 
in milliseconds. 


Throughput (not used if class 0 is the preferred class) 
Parameter code: 1000 1001 


Parameter length: 12 or 24 
Parameter value: 


Ist 12 Octets: maximum throughput, as follows: 

lst 3 octets: Target value, calling-called user 
direction 

2nd 3 octets: Min. acceptable, calling-called user 
direction 

3rd 3 octets: Target value, called-calling user 
direction 

4th 3 octets: Min. acceptable, called-calling user 
direction 

2nd 12 octets (optional): average throughput, as follows: 

5th 3 octets: Target value, calling-called user 
direction 
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6th 3 octets: 


Tth 3 octets: 


8th 3 octets: 


Where the average throughput is omitted, 


Values are expressed in octets per second. 


Residual error rate 


class) 

Parameter code: 
Parameter length: 
lst 3 octets: 

2nd 3 octets: 

3rd 3 octets: 


4th 3 octets: 


Residual error rate 


class) 


Parameter code: 
Parameter length: 
Parameter value: 
lst octet: 


2nd octet: 


Min. acceptable, calling-called user 
direction 
Target value, called-calling user 
direction 
Min. acceptable, called-calling user 
direction 
it is considered 
to have the same value as the maximum throughput. 

(not used if class 0 is the preferred 
1000 1001 
12 
Target value, calling-called user 
direction 
Min. acceptable, calling-called user 
direction 
Target value, called-calling user 
direction 
Min. acceptable, called-calling user 
direction 

(not used if class 0 is the preferred 
1000 0110 
3 
Target value, power of 10 
Min. acceptable, power of 10 
TSDU size of interest, expressed as a 


3rd octet: 


Priority 


Parameter code: 
Parameter length: 
Parameter value: 


(not used 


power of 2 


if class 0 is the preferred class) 


1000 0111 
2 
Integer 
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(0 is the highest priority) 


n) Transit delay (not used if class 0 is the preferred class) 


Parameter code: 1000 1000 

Parameter length: 8 

Parameter value: 

lst 2 octets: Target value, calling-called user 
direction 

2nd 2 octets: Max. acceptable, calling-called user 
direction 

3rd 2 octets: Target value, called-calling user 
direction 

4th 2 octets: Max. acceptable, called-calling user 
direction 


Values are expressed in milliseconds, and are based upon a 
TSDU size of 128 octets. 


p) assignment time (not used if class 0, 2 or class 4 is the 
preferred class) 


This parameter conveys the Time to Try Reassignment (TTR) 
which will be used when following the procedure for 
Reassignment after Failure (see 6.12). 


Parameter code: 1000 1011 
Parameter length: 2 
Parameter value: n, a binary number where n is the TTR 


value expressed in seconds. 


13.3.5 User Data (Octets p+1 to the end) 


No user data are permitted in Class 0, and are optional in the 
other classes. Where permitted, it may not exceed 32 octets. 
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13.4 Connection Confirm (CC) TPDU 
13.4.1 Structure 


The structure of the CC TPDU shall be as follows: 


1 2 3 4 5 6 7 8 p p+1 end 
4---4----+---+---+4+---4+---4---4+------- 4+-------- 4+------------- + 
|LI | CC CDT|DST-REF|SRC-REF| CLASS |VARIABLE| USER 
| |1101] | | | | | OPTION| PART | DATA 
+---+----+---+---+---+---+---+------- 4+-------- 4+------------- + 
13.4.2 LI 
See 13.2.1 


13.4.3 Fixed Part (Octets 2 to 7) 


The fixed part shall contain: 


a) CC: Connection Confirm Code: 1101. Bits 8-5 of octet 2; 


b) CDT: Initial Credit Allocation (set to 0000 in Classes 


and 1). Bits 4-1 of octet 2; 


c) DST-REF: Reference identifying the requested transport 


connection at the remote transport entity; 


d) SRC-REF: Reference identifying the requested transport 


connection at the remote transport entity. 


e) Class and Option: Defines the selected transport protocol 
class and option to be operated over the accepted 


transport connection according to the negotiation 
specified in 6.5; 
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13.4.4 Variable Part (Octet 8 to p) 
The parameters are defined in 13.3.4 and are subject to the 
constraints states in 6.5 (connection establishment). Parameters 


ruled out by selection of an alternative class and option shall 
not be present. 


13.4.5 User Data (Octets p+1 to the end) 
No user data are permitted in class 0, and are optional in the 
other classes. Where permitted, it may not exceed 32 octets. 


The user data are subject to the constraints of the negotiation 
rules (see 6.5). 


13.5 Disonnect Request (DR) TPDU 
13.5.1 Structure 


The structure of the DR TPDU shall be as follows: 


1 2 3 4 5 6 7 8 p pti end 
4+--4+--------- 4+----+----- 4+----+----- 4+------ 4+-------- 4+---------- + 
LI DR DST-REF. | SRC-REF. |REASON|VARIABLE| USER 
1000 0001 | | PART DATA 
+--+--------- +----+----- 4+----+----- 4+------ 4+-------- 4+---------- + 
1345.2 1T 


See Section 13.2.1 
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13.5.3 Fixed Part (Octets 2 to 7 
The fixed part shall contain: 


a) DR: Disconnect Request Code: 1000 0000; 


b) DST-REF: Reference identifying the transport connection 


at the remote transport entity; 


c) SRC-REF: Reference identifying the transport connection 
at the transport entity initiating the TPDU. Value zero 


when reference is unassigned; 


d) REASON: Defines the reason for disconnecting the 
transport connection. This field shall take one of the 
following values: 

The following values may be used for Classes 1 to 4: 

1) 128 + 0 - Normal disconnect initiated by session 
entity 

2) 128 + 1 - Remote transport entity congestion at 
connect request time 

3) *128 + 2 - Connection negotiation failed (i.e. proposed 
class(es) not supported) 

4) 128 + 3 - Duplicate source reference detected for the 
same pair of NSAPS. 

5) 128 + 4 - Mismatched references 

6) 128 + 5 - Protocol error 

7) 128 + 6 - Not used 

8) 128 + 7 - Reference overflow 

9) 128 + 8 - Connection request refused on this network 
connection 


10) 128 + 9 - Not used 
11) 128 + 10- Header or parameter length invalid 


130 


The following values can be used for all classes: 


12) 0 — Reason not specified 

13) 1 - Congestion at TSAP 

14) *2 — Session entity not attached to TSAP 
15) *3 - Address unknown 


NOTE - Reasons marked with an asterisk (*) may be reported to 
the TS-user as persistent, other reasons as transient. 


13.5.4 Variable Part (Octets 8 to p) 
The variable part may contain 


a) A parameter allowing additional information related to the 
clearing of the connection. 


Parameter code: 1110 0000 

Parameter length: Any value provided that the length of 
the DR TPDU does not exceed the maximum 
agreed TPDU size or 128 when the DR 
TPDU is used during the connection 
refusal procedure 

Parameter value: Additional information. The content of 
this field is user defined. 


b) Checksum (see 13.2.3.1) 


13.5.5 User Data (Octets p+1 to the end) 


This field shall not exceed 64 octets and is used to carry TS- 
user data. The successful transfer of this data is not 
guaranteed by the transport protocol. When a DR TPDU is used in 
Class 0 it shall not contain this field. 
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13.6 Disconnect Confirm (DC) TPDU 


This TPDU shall not be used in Class 0. 


13.6.1 Structure 


The structure of DC TPDU shall be as follows: 


1 2 3 4 5 6 7 p 
4+----+----------- 4+----- 4+----- 4+----- 4+----- 4+------- 4+-------- + 
| uz | DC | DST REF | SRC REF | Variable Part | 
| | 1100 0000 | | | | | | | 
4+----+----------- 4+----- 4+----- 4+----- 4+----- 4+------- 4+-------- + 
13.6.2 LI 
See 13.42.31 


13.6.3 Fixed Part (Octets 2 to 6) 

The fixed part shall contain: 
a) DC: Disconnect Confirm Code: 1100 0000; 
b) DST-REF: See 13.4.3; 


c) SRC-REF: See 13.4.3. 
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13.6.4 Variable Part 


The variable part shall contain the checksum parameter if the 
condition in (see 13.2.3.1) applies. 


13.7 Data (DT) TPDU 
13.7.1 Structure 


Depending on the class and the option the DT TPDU shall have one 
of the following structures. 


a) Normal format for Classes 0 and 1 


1 2 3 4 5 end 
4+----+----------- +—----------- +------------ oo + 
[ET] DT | TPDU-NR | User Data | 
| | 1111 0000 | and EOT | | 
+—----+----------- +----------- Ho - - = = oo + 

b) Normal format for Classes 2, 3 and 4 

1 2 3 4 5 6 p p+1 end 
+----+--------- +---+---+------- +----- +------- +----------- - - -+ 

LI DT DST-REF | TPDU-NR|Variable Part |User Data 

1111 0000 | and EOT | 
+----+--------- +---+---+------- oo +------- +----------- - - -+ 
c) Extended Format for use in Classes 2, 3 and 4 when 
selected during connection establishment. 

1 2 3 4 5,6 7,8 9 p ptl end 
+----+--------- +—---+---+4--------- +-------- +---------- - - -+ 
[Es | BE |DST-REF| TPDU-NR |Variable|User Data | 
| |1111 0000| | | and EOT | Part | | 
+----+--------- +---+---+--------- +------—- +--------—- - - -+ 
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130 7.2 


LI 


see 132.1 
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Fixed Part 


The fixed part shall contain: 


DT: 
DST-REPF : 
EOT: 
TPDU-NR: 


Data Transfer Code: 1111 0000; 
See 13.4.3; 


When set to ONE, indicates that the current DT 
TPDU is the last data unit of a complete DT TPDU 
sequence (End of TSDU). EOT is bit 8 of octet 3 
in class 0 andi, bit 8 of octet 5 for normal 
formats for classes 2, 3 and 4 and bit 8 of 
octet 8 for extended formats; 


TPDU send Sequence Number (zero in Class 0). 
May take any value in Class 2 without explicit 
flow control. TPDU-NR is bits 7-1 of octet 3 
for classes 0 and 1, bits 7-1 of octet 5 for 
normal formats in classes 2, 3 and 4, octets 5, 
6 and 7 together with bits 7-1 of octet 8 for 
extended formats. 


NOTE - Depending on the class, the fixed part of the DT  TPDU 
uses the following octets: 


Classes 0 and 1: Octets 2 to 3; 
Classes 2,3,4 normal format: Octets 2 to 5; 
Classes 2,3,4 extended format: Octets 2 to 8. 
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13.7.4 Variable Part 


The variable part shall contain the checksum parameter if the 
condition in see 13.2.3.1 applies. 


13.7.5 User Data Field 
This field contains data of the TSDU being transmitted. 


NOTE - The length of this field is limited to the negotiated TPDU 
size for this transport connection minus 3 octets in Classes 0 
and 1, and minus 5 octets (normal header format) or 8 octets 
(extended header format) in the other classes. The variable 
part, if present, may further reduce the size of the user data 
field. 


13.8 Expedited Data (ED) TPDU 
The ED TPDU shall not be used in Class 0 or in Class 2 when the 


no explicit flow control option is selected or when the expedited 
data transfer service has not been selected for the connection. 


13.8.1 Structure 


Depending on the format negotiated at connection establishment 
the ED TPDU shall have one of the following structures: 
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a) Normal Format (classes 1, 2, 3, 4) 


1 2 3 4 5 6 p p+1 ... end 
Ho ooo +—---+---+4--------- +----- +------- 4+--------------- + 
|LT| ED | DST-REF | EDTPDU-NR| Variable Part|User Data | 
| |0001 0000} | land EOT | | 
+--+--------- +---+---+4--------- +----- +------- +--------------- + 

b) Extended Format (for use in classes 2, 3, 4 when selected 

during connection establishment). 

1 2 3 4 5,6,7,8 9 p p+1 end 
+--+--------- +---+---+--------- Yoo +------- 4+--------------- + 
|LT| ED | DST-REF | EDTPDU-NR|Variable Part|User Data | 
| |0001 0000} | land EOT | | | | 
+--+--------- +---+---+--------- oo +------- +--------------- + 
13.8.2 LI 
See 13.2.1 
13.8.3 Fixed Part 
The fixed part shall contain: 

a) ED: Expedited Data code: 0001 0000; 

b) DST-REF: see 13.4.3; 

Cc) ED-TPDU-NR: Expedited TPDU identification number. ED- 
TPDU-NR is used in classes 1, 3 and 4 and may 
take any value in Class 2. Bits 7-1 of octet 
5 for normal formats and octets 5, 6 and 7 
together with bits 7-1 of octet 8 for 


extended formats; 
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d) EOT: end of TSDU always set to 1 (bit 8 of octet 5 
for normal formats and bit 8 of octet 8 for 
extended formats). 


NOTE - Depending on the format the fixed part shall be either 
octets 2 to 5 or 2 to 8. 


13.8.4 Variable Part 


The variable part shall contain the checksum parameter if the 
condition defined in 13.2.3.1 applies. 


13.8.5 User Data Field 


This field contains an expedited TSDU (1 to 16 octets). 


13.9 Data Acknowledgement (AK) TPDU 
This TPDU shall not be used for Class 0 and Class 2 when the "no 


explicit flow control" option is selected, and for Class 1 when 
the network receipt confirmation option is selected. 


13.9.1 -Structure 


Depending on the class and option agreed the AK TPDU shall have 
one of the following structures: 
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a) Normal Format (classes 1, 2, 3, 4) 


b) Extended Fo 


rmat (for use in classes 2, 3, 4 when selected 


during connection establishment). 


1 2 3 
+--+--------- +---- 
|LI| A, | DST 
| |0110 0000| 
+--+--------- +---- 
1379.2. LI 
See 13.02.31 


13.9.3 Fixed Part 


4 5,6,7,8 9,10 11 p 


+ 
| 
| | Part | 
+ 


The fixed part shall contain (in octet 2 to 5 when normal format 
is used, 2 to 10 otherwise) the following parameters: 


a) AK: 


b) CDT: 


c) DST-REF: 


d) YR-TU-NR: 


Acknowledgement code: 0110; 

Credit Value (set to 1111 in class 1). Bits 
4-1 of octet 2 for normal formats and octets 9 
and 10 for extended formats; 

See 13.4.3; 

Sequence number indicating the next expected DT 


TPDU number. For normal formats, bits 7-1 of 
octet 5; bit 8 of octet 5 is not significant 
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13.9.4 


and shall take the value 0. For extended 
formats, octets 5, 6 and 7 together with bits 
7-1 of octet 8; bit 8 of octet 8 is not 
significant and shall take the value 0. 


Variable Part 


The variable part contains the following parameters: 


a) 


Checksum See 13.2.3.1 if the condition in LS 32% 324 
applies; 


Subsequence number when optionally used under the 


conditions defined in class 4. This parameter is used to 
ensure that AK TPDUs are processed in the correct 
sequence. If it is absent, this is equivalent to 
transmitting the parameter with a value of zero. 

Parameter code: 1000 1010 

Parameter length: 2 

Parameter value: 16-bit sub-sequence number; 


Flow Control Confirmation Class 4 when optionally used 
under the conditions defined in class 4. This parameter 
contains a copy of the information received in an AK TPDU, 
to allow the transmitter of the AK TPDU to be certain of 


the state of the receiving transport entity (see 
WD 23 LO) 

Parameter code: 1000 1011 

Parameter length: 8 

Parameter value: defined as follows 


1. Lower Window Edge (32 bits) 
Bit 8 of octet 4 is set to zero, the remainder 
contains the YR-TU-NR value of the received AK TPDU. 
When normal format has been selected, only the least 
significant seven bits (bits 1 to 7 of octet 1) of 
this field are significant. 


2. Your Sub-Sequence (16 bits) 
Contains the value of the sub-sequence parameter of 
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the received AK  TPDU, or zero if this parameter was 
not present. 


3. Your Credit (16 bits) 
Contains the value of the CDT field of the received AK 
TPDU. When normal format has been selected, only the 


least significant four bits (bits 1 to 4 of octet 1) 
of this field are significant. 


13.10 Expedited Data Acknowledgement (EA) TPDU 


This TPDU shall not be used for Class 0 and Class 2 when the no 
explicit flow control option is selected. 


13.10.1 Structure 


Depending on the option (normal or extended format) the TPDU 
structure shall be: 


a) Normal Format (classes 1,2,3,4) 


1 2 3 4 5 6 p 
4+--+--------- 4+--------- 4+---------- $ 4+------ + 
|LI| EA | DST-REF | YR-TU-NR |Variable Part | 
| |0010 0000} | | | | 
4+--+--------- 4+--------- 4+---------- 4+------ 4+------ + 


b) Extended Format (for use in classes 2, 3, 4 if selected 
during connection establishment) 


1 2 3 4 5,6,7,8 9 p 
4+--+--------- 4+--------- 4+---------- 4+------ 4+------ + 
|LI| EA | DST-REF | YR-TU-NR |Variable Part | 
| |0010 0000} | | | | 
4+--+--------- 4+--------- 4+---------- 4+------ Ho + 
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13.10.2 LI 


See 13.2.1 


13.10.3 Fixed Part 


The fixed part shall contain (in octets 2 to 5 when normal format 
is used, in octets 2 to 8 otherwise): 


a) EA: Expedited Acknowledgement code: 0010 0000; 
b) DST-REF: See 13.4.3; 


c) YR-EDTU-NR: Identification of the ED TPDU being 
acknowledged. May take any value in Class 2; 


For normal formats bits 7-1 of octet 5; bit 8 
of octet 5 is not significant and shall take 
the value 0. For extended formats, octets 
5,6 and 7 together with bits 7-1 of octet 8; 


bit 8 of octet 8 is not significant and shall 
take the value 0. 


13.10.4 Variable Part 


The variable part may contain the checksum parameter (see 
133.2636 e 


13.11 Reject (RJ) TPDU 


The RJ TPDU shall not be used in Classes 0, 2 and 4. 
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13.11.1 Structure 
The RJ TPDU shall have one of the following formats: 


a) Normal Format (classes 1 and 3) 


if 2 3 4 5 
4+----4---------- 4+----4----+4------------ + 
| LI | RJ CDT | DST-REF | YR-TU-NR | 
| | 0101 | | | | 
4+----4---------- 4+----4----+4------------ + 


b) Extended Format (for use in classes 3 if selected during 
connection establishment). 


13.db32° bi 


SEAS, Zed 


13.11.3 Fixed Part 


The fixed part shall contain (in octets 2 to 5 when normal format 
is used, in octets 2 to 10 otherwise): 


a) RJ: Reject Code: 0101. Bits 8-5 of octet 2; 
p) CDT: Credit Value (set to 1111 in class 1). Bits 
4-1 of octet 2 for normal formats and octets 9 


and 10 for extended formats; 


c) DST-REF: See 13.4.3; 
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d) YR-TU-NR: Sequence number indicating the 


TPDU from which retransmission should occur. 


For normal formats, bits 7-1 of octet 5; 
of octet 5 is not significant and shall take 
the value 0. For extended formats, 
and 7 together with bits 7-1 of octet 8; 


of octet 8 is not significant 
the value 0. 


13.11.4 Variable Part 


There is no variable part for this TPDU type. 


13.12 TPDU Error (ER) TPDU 


13.12.1 Structure 


1 2 3 4 5 6 P 
4----4----------- 4----4----+-------- 4+---------- + 
na | ER | DST-REF | Reject | Variable | 
| | 0111 0000 | | | Cause | Part | 
4----4----------- 4----4----+-------- 4+---------- + 


13.12.2 LI 


See 13.2.1 
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13.12.3 


Fixed Part 


The fixed part shall contain: 


13.12.4 


The var 


a) 


ER: TPDU Error Code: 0111 0000; 

DST-REF: See 13.4.3; 

REJECT CAUSE: 0000 0000 Reason not specified 
0000 0001 Invalid parameter code 


0000 0010 Invalid TPDU type 
0000 0011 Invalid parameter value. 


Variable Part 

iable part may contain the following parameters: 

Invalid TPDU 

Parameter code: 1100 0001 

Parameter length: number of octets of the value field 

Parameter Value: Contains the bit pattern of the rejected 
TPDU up to and including the octet 
which caused the rejection. This 
parameter is mandatory in Class 0. 


Checksum 


This parameter shall be present if the condition in 
13.2.3.1 applies. 
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SECTION THREE. CONFORMANCE 


14 CONFORMANCE 
14.1 


A system claiming to implement the procedures specified in this 
standard shall comply with the requirements in 14.2 - 14.5. 


1:42 


The system shall implement Class 0 or Class 2 or both. 


14.3 


If the system implements Class 3 or Class 4, it shall also 
implement Class 2. 


14.4 


If the system implements Class 1, it shall also implement Class 
0. 
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14. 


5 


For each class which the system claims to implement, the system 
shall be capable of: 


14. 


a) 


6 


a) 


b) 


initiating CR TPDUs or responding to CR TPDUs with CC 
TPDUs or both; 


responding to any other TPDU and operating network service 
in accordance with the procedures for the class; 


operating all the procedures for the class listed as 
mandatory in table 9; 


operating those procedures for the class listed as 
optional in table 9 for which conformance is claimed; 


handling all TPDUs of lengths up to the lesser value of: 
1) the maximum length for the class; 
2) the maximum for which conformance is claimed. 


NOTE - This requirement indicates that TPDU sizes of 128 
octets are always implemented. 


Claims of Conformance Shall State 


which class or classes of protocol are implemented; 


whether the system is capable of initiating or responding 
to CR TPDUs or both; 


which of the procedures listed as optional in table 9 are 
implemented; 
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the maximum size of TPDU implemented; the value shall be 
chosen from the following list and all values in the list 
which are less than this maximum shall be implemented: 


128, 256, 512, 1024, 2048, 4096 or 8192 octets. 
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| PROCEDURE | CLASS 0 | CLASS 1 
eee ee tan ae 
|TPDU with checksum | NA | NA 
|TPDU wihout checksum | mandatory | mandatory 
|Expedited data transfer | NA | mandatory 
|No expedited data transfer | mandatory | mandatory 
| | 
| | | 
Flow control in Class 2 NA NA 
Be flow control in Class A NA | NA 
| 
ve eh ae A ieee 
|Normal formats | mandatory | mandatory 
|Extended formats | NA | NA 
|Use of receipt confirma- | | 
[tion in Class 1 | NA | optional 
|No use of receipt con- | 
|firmation in Class 1 | NA | mandatory 
|Use of network expedited | | 
|in Class 1 | NA | optional 
[No use of network expedi- | | 
[ted in Class 1 | NA | mandatory 
| | 


NA indicates the procedure is not applicable. 
Table 9. (First of 2 pages) Provision of options 
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| PROCEDURE | crass 2 | CLASS 3 | CLASS 4 
| | --—-—-- |---------- |-----=----- 
ee with checksum a a mandatory 
|TPDU wihout checksum [mandatory |mandatory |optional 
| | | | 
|----=---=-----------=----- |---------- |---------- |----------- 
[Expedited data transfer [mandatory |mandatory |mandatory 
|No expedited data transfer |mandatory |mandatory |mandatory 
| Flow control in Class 2 |mandatory |NA [NA 
|No flow control in Class 2|optional [NA |NA 
| | | 
E Bc ccoa as |---------- | ---------- | > 
Normal formats mandatory |mandatory |mandatory 
bees formats optional optional optional 
| | 
Dae Ba! ee a 
|Use of receipt confirma- | | | 
[tion in Class 1 [NA [NA [NA 
No use of receipt con- 
firmation in Class 1 NA NA NA 
| | | | 
passe ss E Rose [Ease=as=55 [z= |a= 
|Use of network expedited | | 
lin Class 1 | Na | Na [NA 
No use of network expedi- 
ted in Class 1 NA NA NA 
| | | 


NA indicates the procedure 
Table 9. (Second of 


is not applicable 


2 pages) 
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Provision of options 


ANNEX A - STATE TABLES 


This annex is an integral part of the body of this International 
Standard. 


This Annex provides a more precise description of the protocol. 
In the event of a discrepancy between the description in these 
tables and that contained in the text, the text takes precedence. 


The state table also define the mapping between service and 
protocol events that TS-users can expect. 


This annex describes the transport protocol in terms of state 
tables. The state tables show the state of a transport 
connection, the events that occur in the protocol, the actions 
taken and the resultant state. 


[The state tables have been omitted from this copy.] 
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ANNEX B - CHECKSUM ALGORITHMS 


(This annex is provided for information for implementors and is 
not an integral part of the body of the standard.) 


B.1 SYMBOLS 
The following symbols are used: 


CO variables used in the algorithms 
Cl 


i number (i.e. position) of an octet within the TPDU (see 
12.1) 


n number (i.e. position) of the first octet of the checksum 
parameter 


L length of the complete TPDU 
X value of the first octet of the checksum parameter 


Y value of the second octet of the checksum parameter. 


B.2 ARITHMETIC CONVENTIONS 
Addition is performed in one of the two following modes: 
a) modulo 255 arithmetic; 
b) one’s complement arithmetic in which if any of the 


variables has the value minus zero (i.e. 255) it shall be 
regarded as though it was plus zero (i.e. 0). 


B.3 ALGORITHM FOR GENERATING CHECKSUM PARAMETERS 
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B.3.1 Set up the complete TPDU with the value of the checksum 
parameter field set to zero. 


B.3.2 Initialize CO and Cl to zero. 


B.3.3 Process each octet sequentially from i= 1 to L by: 


a) adding the value of the octet to CO; then 


b) adding the value of CO to Cl. 


B.3.4 Calculate X and Y such that 


X = -C1 + (L-n).CO 
Y = Cl - (L-n+1).C0 


B.3.5 Place the values X and Y in octets n and (n + 1) 
respectively. 


[A Note describing the above algorithm in mathematical notation 
has been omitted from this copy.] 


B.4 ALGORITHM FOR CHECKING CHECKSUM PARAMETERS 


B.4.1 Initialize CO and Cl to zero. 


B.4.2 Process each octet of the TPDU sequentially from i = 1 to 


a) adding the value of the octet to C0; then 


b) adding the value of C0 to Cl. 
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B.4.3 If, when all the octets have been processed, either or 
both of CO and Cl does not have the value zero, the checksum 
formulas in 6.17 have not been satisfied. 


NOTE - The nature of the algorithm is such that it is not 
necessary to compare explicitly the stored checksum bytes. 
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Explanatory Report 


The Transport Layer Services and Protocols have been under study 
within TC97/SC16 since 1979. It was agreed by SC16 at its 
meeting in Berlin, November 1980, that the Service and Protocol 
documents would be progressed concurrently. 


At the SC16 meeting in Tokyo, June 1982, authorization was given 
(Resolutions 10 and 11, SC16 N 1233) to register both the 
Transport Service Definition and the Transport Protocol 
Specification as Draft Proposals and to circulate them for a 90- 
day ballot. 


Following the close of the letter ballot an Editing Group was 
convened to integrate editorial comments and make recommendations 
regarding proposed technical changes. The revised texts and 
proposed recommendations were reviewed by SC16/WG6 at its meeting 
in Vienna, March 1983. The revised text of the Transport Service 
Definition (SC16 N 1435) was accepted as presented whereas the 
revised text of the Transport Protocol (SC16 N 1433) was 
subjected to an additional 60-day ballot. Consistent with the 
sc16 decision regarding the parallel progression of both DPs, the 


Transport Service Definition was held in abeyance pending 
acceptance by SC16 of the revised Transport Protocol (Second DP 
8073). 


A second Editing Group was convened in Paris, July 1983, to 
review comments submitted on Second DP 8073. The Minutes and 
Report of this meeting are documented in SC16 N1575 and N 1574 
respectively. The two negative votes (DIN and NNI) were given 
full consideration. The NNI concerns have been fully covered in 
the revised text prepared by the Editing Group. The DIN concerns 
have been taken into account and incorporated in their large 
majority. 


Upon the recommendation of the Editing Group, DP 8072 and DP 8073 
are forwarded for registration as Draft International Standards 
and letter ballot of ISO Member Bodies. 
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